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