Re: Update on the progress of slew development

From: Casper Ti. Vector <>
Date: Sat, 4 May 2019 14:07:04 +0800

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] <>

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

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC