killing a large lists of pids - Unix

This is a discussion on killing a large lists of pids - Unix ; Say I have the following list of pids... 8, 2, 5, 4, 3, 9, 7, 11 I've seen some code where people would sort the pids before killing them. What is the possible advantage of this? If you already have ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: killing a large lists of pids

  1. killing a large lists of pids

    Say I have the following list of pids...
    8, 2, 5, 4, 3, 9, 7, 11

    I've seen some code where people would sort the pids before killing
    them. What is the possible advantage of this? If you already have the
    list of pids, couldn't you just traverse the list, killing each one
    along the way?


    Chad

  2. Re: killing a large lists of pids

    "K-mart Cashier" schrieb im Newsbeitrag
    news:b8fd69dd-8498-491b-8e91-b84f281de196@s19g2000prg.googlegroups.com...
    > Say I have the following list of pids...
    > 8, 2, 5, 4, 3, 9, 7, 11
    >
    > I've seen some code where people would sort the pids before killing
    > them. What is the possible advantage of this? If you already have the
    > list of pids, couldn't you just traverse the list, killing each one
    > along the way?

    Guess the reason is that typically the parent processes have lower PIDs and
    killing parents may take the children along

    Bye, Joo



  3. Re: killing a large lists of pids

    On Nov 29, 8:54 am, K-mart Cashier wrote:
    > Say I have the following list of pids...
    > 8, 2, 5, 4, 3, 9, 7, 11
    >
    > I've seen some code where people would sort the pids before killing
    > them. What is the possible advantage of this? If you already have the
    > list of pids, couldn't you just traverse the list, killing each one
    > along the way?
    >
    > Chad


    for pid in "8 2 5 4 3 9 7 11"
    do
    kill $pid
    done


  4. Re: killing a large lists of pids

    On Nov 29, 6:41 am, Benoit Lefebvre wrote:
    > On Nov 29, 8:54 am, K-mart Cashier wrote:
    >
    > > Say I have the following list of pids...
    > > 8, 2, 5, 4, 3, 9, 7, 11

    >
    > > I've seen some code where people would sort the pids before killing
    > > them. What is the possible advantage of this? If you already have the
    > > list of pids, couldn't you just traverse the list, killing each one
    > > along the way?

    >
    > > Chad

    >
    > for pid in "8 2 5 4 3 9 7 11"
    > do
    > kill $pid
    > done


    One some "idle" killers for both the IRC and FreeBSD, the programmer
    would like like

    getpids
    sort pids
    kill user process that didn't hit ctrl-d

    getpids
    sortpids
    kill detached processes

    getpids
    sortpids
    kill daemons of users that aren't looged in


  5. Re: killing a large lists of pids

    On Nov 29, 9:41 am, Benoit Lefebvre wrote:
    > On Nov 29, 8:54 am, K-mart Cashier wrote:
    >
    > > Say I have the following list of pids...
    > > 8, 2, 5, 4, 3, 9, 7, 11

    >
    > > I've seen some code where people would sort the pids before killing
    > > them. What is the possible advantage of this? If you already have the
    > > list of pids, couldn't you just traverse the list, killing each one
    > > along the way?

    >
    > > Chad

    >
    > for pid in "8 2 5 4 3 9 7 11"
    > do
    > kill $pid
    > done


    Depending on what you're trying to demonstrate, don't you have to lose
    the dquotes, e.g.:

    for pid in 8 2 5 4 3 9 7 11
    do
    kill $pid
    done

    ?

  6. Re: killing a large lists of pids

    On Nov 29, 5:54 am, K-mart Cashier wrote:
    > Say I have the following list of pids...
    > 8, 2, 5, 4, 3, 9, 7, 11
    >
    > I've seen some code where people would sort the pids before killing
    > them. What is the possible advantage of this? If you already have the
    > list of pids, couldn't you just traverse the list, killing each one
    > along the way?


    Of course. I think the only reason to sort would be for "neatness",
    the same reason glob(3) sorts its output. For example, if some of the
    kills fail, the error messages will appear in numerical order, which
    might make them easier to read. But there's no functional reason that
    I can imagine.

  7. Re: killing a large lists of pids

    fjblurt@yahoo.com wrote:
    > On Nov 29, 5:54 am, K-mart Cashier wrote:
    > > Say I have the following list of pids...
    > > 8, 2, 5, 4, 3, 9, 7, 11
    > >
    > > I've seen some code where people would sort the pids before killing
    > > them. What is the possible advantage of this? If you already have the
    > > list of pids, couldn't you just traverse the list, killing each one
    > > along the way?


    > Of course. I think the only reason to sort would be for "neatness",
    > the same reason glob(3) sorts its output. For example, if some of the
    > kills fail, the error messages will appear in numerical order, which
    > might make them easier to read. But there's no functional reason that
    > I can imagine.


    Especially on systems like OpenBSD, which randomize PIDs.


  8. Re: killing a large lists of pids

    JS> Guess the reason is that typically the parent processes have
    JS> lower PIDs and killing parents may take the children along

    But, conversely, killing the children first would often tend to cause
    the parents to exit of their own accord, if (for example) the parents
    were shells executing a command pipeline.

    Both of these are superficially attractive rationales. But they both
    break down. In reality, process IDs are not guaranteed to be created
    in _any_ order. So sorting process IDs into ascending or descending
    numerical order doesn't yield any particular order of the processes
    that have those IDs. The only reasons for sorting would be aesthetic
    ones, not functional ones.

  9. Re: killing a large lists of pids

    In article
    ,
    Benoit Lefebvre wrote:

    > On Nov 29, 8:54 am, K-mart Cashier wrote:
    > > Say I have the following list of pids...
    > > 8, 2, 5, 4, 3, 9, 7, 11
    > >
    > > I've seen some code where people would sort the pids before killing
    > > them. What is the possible advantage of this? If you already have the
    > > list of pids, couldn't you just traverse the list, killing each one
    > > along the way?
    > >
    > > Chad

    >
    > for pid in "8 2 5 4 3 9 7 11"
    > do
    > kill $pid
    > done


    Why the for loop, rather than:

    kill 8 2 5 4 3 9 7 11
    --
    Barry Margolin
    Arlington, MA

  10. Re: killing a large lists of pids

    Barry Margolin wrote:
    >> for pid in "8 2 5 4 3 9 7 11"
    >> do
    >> kill $pid
    >> done

    >
    > Why the for loop, rather than:
    >
    > kill 8 2 5 4 3 9 7 11


    Ironically, that's what the quotes end up doing.

    HT

  11. Re: killing a large lists of pids

    J de Boyne Pollard wrote:

    > JS> Guess the reason is that typically the parent processes have
    > JS> lower PIDs and killing parents may take the children along
    >
    > But, conversely, killing the children first would often tend to cause
    > the parents to exit of their own accord, if (for example) the parents
    > were shells executing a command pipeline.
    >
    > Both of these are superficially attractive rationales. But they both
    > break down. In reality, process IDs are not guaranteed to be created
    > in _any_ order.


    To add to that...even if you know that the particular system this will be
    done on does indeed allocate PIDs sequentially, it still breaks down when
    the maximum PID value is reached and they roll back over.

    --
    Kurt M. Weber


  12. Re: killing a large lists of pids

    J de Boyne Pollard wrote:
    > JS> Guess the reason is that typically the parent processes have
    > JS> lower PIDs and killing parents may take the children along


    > But, conversely, killing the children first would often tend to cause
    > the parents to exit of their own accord, if (for example) the parents
    > were shells executing a command pipeline.
    >
    > Both of these are superficially attractive rationales. But they both
    > break down. In reality, process IDs are not guaranteed to be created
    > in _any_ order.


    On the other hand, in a particular situation, it might be a given that
    since you're going around killing processes in a wholesale fashion, you
    are in a situation where there's already no way to guarantee you'll be
    gracefully/correctly shutting down things. In that case, a heuristic
    approach that increases the odds of not screwing too much stuff up[1]
    might be helpful.

    Sort of like typing "sync" and waiting 5 seconds before you unplug the
    power cord rather than simply unplugging the power cord without a "sync".
    Neither is correct and neither guarantees you anything, but if you have
    to choose between the two, one is somewhat better than the other.

    - Logan

    [1] by taking advantage of the strong positive correlation between
    the smaller-pid/larger-pid relationship and the parent/child
    relationship that exists on many systems

  13. killing a large lists of pids

    JS> Guess the reason is that typically the parent processes have
    JS> lower PIDs and killing parents may take the children along

    JdeBP> But, conversely, killing the children first would often
    JdeBP> tend to cause the parents to exit of their own accord,
    JdeBP> if (for example) the parents were shells executing a
    JdeBP> command pipeline.
    JdeBP>
    JdeBP> Both of these are superficially attractive rationales.
    JdeBP> But they both break down. In reality, process IDs
    JdeBP> are not guaranteed to be created in _any_ order.

    LS> On the other hand, in a particular situation, it might
    LS> be a given that since you're going around killing
    LS> processes in a wholesale fashion, you are in a
    LS> situation where there's already no way to guarantee
    LS> you'll be gracefully/correctly shutting down things.
    LS> In that case, a heuristic approach that increases
    LS> the odds of not screwing too much stuff up[1]
    LS> might be helpful.

    That isn't really on the other hand at all. It's going back from the
    _gripping_ hand, that _both_ approaches break down, to picking one of
    those approaches from the one hand or the other. And it's ignoring
    the point made on the gripping hand that in some parent-child
    relationships (e.g. command pipelines) killing the children first is
    better and in other parent-child relationships (e.g. daemon
    supervisors) killing the parents first is better, and that on any
    system one is going to have a combination of both. So even if one had
    used some additional mechanism, not provided by the process IDs alone,
    to figure out reliably which processes are the parents and which the
    children, one would still have a dilemma. Hence, of course, it is
    always the better course of action to use some other mechanism to stop
    a system in an orderly manner (e.g. telling the daemon supervisor via
    its control interface to terminate the daemon and then exit itself --
    as "svc -tx" does for "daemontools", for example).

+ Reply to Thread