From: Guillermo <gdiazhartusch@gmail.com>
To: Supervision <supervision@list.skarnet.org>
Subject: Re: race condition in killall
Date: Sat, 11 May 2019 15:29:28 -0300 [thread overview]
Message-ID: <CADQ2Nw8d4HxfTrbPj+PuhzeLSE3Kzz3D_yeSb0DnTkHTBruk1w@mail.gmail.com> (raw)
In-Reply-To: <20190505015551.GF2595@panda>
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.
next prev parent reply other threads:[~2019-05-11 18:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-17 13:25 Update on the progress of slew development Casper Ti. Vector
2019-03-17 14:30 ` Oliver Schad
2019-03-18 14:44 ` Casper Ti. Vector
2019-03-19 12:10 ` Casper Ti. Vector
2019-03-19 12:42 ` Casper Ti. Vector
2019-03-19 15:25 ` Casper Ti. Vector
2019-03-19 15:58 ` Oliver Schad
[not found] ` <20190320051439.GA7636@caspervector>
2019-03-20 5:14 ` Casper Ti. Vector
2019-03-20 11:51 ` Casper Ti. Vector
2019-05-04 6:07 ` Casper Ti. Vector
2019-05-05 1:55 ` race condition in killall sysinit
2019-05-07 14:46 ` Casper Ti. Vector
2019-05-11 18:29 ` Guillermo [this message]
2019-05-11 19:26 ` Laurent Bercot
2019-09-27 17:42 ` Update on the progress of slew development Casper Ti. Vector
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CADQ2Nw8d4HxfTrbPj+PuhzeLSE3Kzz3D_yeSb0DnTkHTBruk1w@mail.gmail.com \
--to=gdiazhartusch@gmail.com \
--cc=supervision@list.skarnet.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).