Re: race condition in killall

From: Guillermo <gdiazhartusch_at_gmail.com>
Date: Sat, 11 May 2019 15:29:28 -0300

El sáb., 4 may. 2019 a las 22:55, sysinit escribió:
>
> > 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.
>
> interesting. i have not considered this at all.
> looks like kill( -1, sig ) from process #1 ensures correctnes here
> in a cheap and simple way.

I haven't looked at pkill or killall, but it should be noted that
killall5 is supposed to *not* send signals to everyone: process 1,
processes in the same session (in the POSIX sense), and processes
specified with the -o option, if given, are excluded. So it has to
retrieve a process list and classify. If the signal is SIGKILL and
killall5 is used in a shell script, the session thing generally allows
the shell process to continue execution after invocation of the
program. And, I suppose, it also allows the process that invoked the
script and maybe other ancestors, such as rc subsystem components, to
continue execution as well.

However, both sysvinit's and BusyBox's kilall5 make a kill(-1,
SIGSTOP) call before going through the PID list and selectively
sending the requested signal (and I guess Linux does not deliver
SIGSTOP to the process that contains the call, or it would be
pointless), and make a kill(-1, SIGCONT) call when they are done, so
I'm not sure if there's actually a race condition.

But yeah, in a version 0.4.x.x s6-linux-init-style setup, where the
stage 3 init can just spawn a process that makes a kill(-1, sig) call,
all this is not needed, and just using 'kill -KILL -1' or some
equivalent is probably the simplest alternative. BTW, the kill program
from procps 3.3.15 segfaulted when I tried to use it with a -1 PID
argument :/ BusyBox's kill applet, as well as Bash's builtin kill
utility (i.e. sh -c 'kill -KILL -1') did work when used like this. I
haven't tried s6-nuke, but I'm assuming it works since
s6-linux-init-04.x.x relies on it, and haven't tried util-linux's and
GNU Coreutils' kill either.

> OpenRC also provides a tool for that task btw:
> /libexec/rc/bin/kill_all

Yeah, ${LIBEXECDIR}/bin/kill_all works like kilall5. OpenRC used to
have a killall5 invocation in its 'killprocs' service script, which
meant a runtime dependency on a package that provided the program.
Probably not a problem in a sysvinit + OpenRC or BusyBox init + OpenRC
setup, but ugly in a 'pure' OpenRC setup (i.e. with openrc-init as
process 1).

G.
Received on Sat May 11 2019 - 18:29:28 UTC