On Wed, Mar 20, 2019 at 01:14:39PM +0800, Casper Ti. Vector wrote:
> pkill(1), killall(1) and killall5(8) all retrieve a process list and
> kill them one by one, instead of calling kill(-1, signal), so a race
> condition can happen thats let some process escape the final SIGKILL.
> Since pkill(1) and killall(1) use regex matching, the probability for
> the race can be significantly larger.
>
> To be 100% sure no process (except for PID 1) escapes that signal, you
> can use `s6-nuke' from s6-portable-utils. `kill -signal -- -1' should
> theoretically do similar things, but kill(1) from coreutils and busybox
> do not seem to behave in this way.
Reading recent posts on this mail list, I have noticed that the sentence
about kill(1) was incorrect because:
* POSIX does not require `kill -signal -- -1', but just `kill -- -1' *in
addition to* `kill -signal -1'.
* `kill -signal -1' does do the desired job, and I erronously thought
it did not, because what I tried was `{/bin/kill,busybox kill} -15 -1'
in the shell of a test user, but the shell trapped SIGTERM (and Linux
does not send the signal to the calling process of kill(-1, signal)).
* coreutils does not implement kill(1); busybox, util-linux and procps
do. Anyway, `kill -{signum,SIGNAME} -1' is required by POSIX.
slew has been updated (commit 593e6174) to use kill(1), and its users
no longer need to worry about the theoretical possibility about
comets [1] escaping the final SIGKILL.
[1] <
https://turing.une.edu.au/~cosc330/lectures/lecture_03/lecture_03.html>
--
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Received on Sat May 04 2019 - 06:07:04 UTC