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
.

Relevant Pages

  • Re: killing a large lists of pids
    ... JS> lower PIDs and killing parents may take the children along ... But, conversely, killing the children first would often tend to cause ...
    (comp.unix.programmer)
  • 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 ... process IDs are not guaranteed to be created ...
    (comp.unix.programmer)