Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

shouldn't most ip-up jobs be backgrounded?

0 views
Skip to first unread message

Dan Jacobson

unread,
Oct 2, 2003, 12:09:11 AM10/2/03
to
Gentlemen, can you suggest a better way for one to wait for all his
jobs to finish, rather than running them in series rather than in
parallel. If I were to run my ip-up jobs in series, it would double
the time of my phone calls.

Why should news fetching have to wait for mail fetching to finish when
each takes only a small amount of bandwidth, but often long times?

Why must one first send his mail before fetching it, or visa versa?
Why can't they be done in parallel? Some smtp servers are
deliberately slow, so one could waste most of a phone call just to
send a few short messages. Parallel is the way to go.

In http://bugs.debian.org/203266, Andreas Metzler writes:

A> I just don't agree. IMHO most of the jobs (including exim4) are not
A> executed in background for a reason: Once /etc/ppp/ip-up/ has
A> finished you can be confident that all the important stuff (fetching
A> mail, sending mail, polling news) has been done and that the line can
A> be safely disconnected.

A> For example I use something[1] like this:
A> -------------------
A> /etc/ppp/ip-up.d/zzzz_disconnectwhendone
A> #!/bin/sh
A> # disconnect after sending mail et.al.
A> if [ "${PPP_IPPARAM}"="expensive" ] ; then
A> # beep
A> printf "\a\n" > /dev/tty1
A> # disconnect
A> sleep 1 && poff
A> fi
A> -------------------

A> and in daytime, when my internet connection is expensive I use
A> pon foo ipparam expensive
A> which just fetches my mail and news and automatically disconnects
A> afterwards.

Good thing you aren't browsing the web at the time.

A> I am not claiming that there are setups where it is better to
A> background the jobs I am just arguing that there seems to be some
A> consistency in choosing not to background the jobs and there are
A> reasons why backgrounding is not inherently better. Having to choose
A> what to prefer I select consistency and my own setup.

What I use is a script to see that all my various http fetches,
netnews postings, outbound smtp queues are really empty, not that just
their processes have finished, before closing the connection.

James Carlson

unread,
Oct 2, 2003, 8:32:34 AM10/2/03
to
[Please don't send me copies by email ... I read this group
regularly. Post here _or_ send me mail.]

Dan Jacobson <jid...@jidanni.org> writes:
> Gentlemen, can you suggest a better way for one to wait for all his
> jobs to finish, rather than running them in series rather than in
> parallel. If I were to run my ip-up jobs in series, it would double
> the time of my phone calls.

It sounds like your disagreement is really with the Debian folks, and
not with pppd itself. Pppd doesn't wait for /etc/ppp/ip-up to finish
executing -- it starts it up in the background (effectively) using the
run_program() function in main.c -- and (more importantly) the
standard pppd package doesn't include *ANY* /etc/ppp/ip-up. The
contents of that file are *supposed* to be provided by the user,
although some distributions of Linux have taken it on themselves to
provide "default" /etc/ppp/ip-up scripts.

Even if it were with pppd, this wouldn't be the right forum. Sending
mail to ppp-...@db.samba.org would be better.

> Why should news fetching have to wait for mail fetching to finish when
> each takes only a small amount of bandwidth, but often long times?

I agree with you. Starting them all up with '&' makes a lot of sense.

> In http://bugs.debian.org/203266, Andreas Metzler writes:
>
> A> I just don't agree. IMHO most of the jobs (including exim4) are not
> A> executed in background for a reason: Once /etc/ppp/ip-up/ has
> A> finished you can be confident that all the important stuff (fetching
> A> mail, sending mail, polling news) has been done and that the line can
> A> be safely disconnected.

Nobody and nothing is watching for /etc/ppp/ip-up to finish running,
so that explanation doesn't really wash for me.

A better approach (if one were to redesign the Debian mechanism here)
would be to provide for synchronization barriers in the script
operation. So, as an off-the-cuff example:

# use 'ls' to get alphabetic sorting
for dir in `/usr/bin/ls /etc/ppp/ip-up.d`
do
if [ -d $dir ]; then
# everything in one directory starts at once
for file in `echo $dir/*`
do
if [ -x $file ]; then
$file &
fi
done
# but we sync between directories
wait
fi
done

That way, you could have /etc/ppp/ip-up.d/1/ and /etc/ppp/ip-up.d/2/
directories, and all the scripts in .../1/ would run at one time and
all those in .../2/ would run at another.

> What I use is a script to see that all my various http fetches,
> netnews postings, outbound smtp queues are really empty, not that just
> their processes have finished, before closing the connection.

Again, your argument is with Debian -- not with PPP or pppd. They're
the folks who've made this policy decision for you.

One thing you could do would be something like this in a single
script:

fetchmail &
newsxfer &
... &
wait

That would preserve the sequential nature that the other users seem to
want, while at least running these tasks in parallel.

--
James Carlson, Solaris Networking <james.d...@sun.com>
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

0 new messages