shouldn't most ip-up jobs be backgrounded? - PPP

This is a discussion on shouldn't most ip-up jobs be backgrounded? - PPP ; 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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: shouldn't most ip-up jobs be backgrounded?

  1. shouldn't most ip-up jobs be backgrounded?

    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.

  2. Re: shouldn't most ip-up jobs be backgrounded?

    [Please don't send me copies by email ... I read this group
    regularly. Post here _or_ send me mail.]

    Dan Jacobson 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-bugs@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
    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

+ Reply to Thread