From: Lennart Poettering <lennart@poettering.net>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl>,
util-linux <util-linux@vger.kernel.org>,
systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] nsenter and SIGSTOP
Date: Sun, 21 Apr 2013 15:21:24 +0200 [thread overview]
Message-ID: <20130421132124.GA11663@tango.0pointer.de> (raw)
In-Reply-To: <87k3nwzvkt.fsf@xmission.com>
On Sat, 20.04.13 15:27, Eric W. Biederman (ebiederm@xmission.com) wrote:
> Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
>
> > Hi,
> > I've hit a bit of a problem with nsenter and systemd-nspawn.
> > When nsenter is used to enter the PID namespace created with
> > systemd-nspawn, and the container's init attempts a shutdown,
> > it hangs because nsenter is suspended.
> >
> > The sequence of events leading to the hang is:
> >
> > 1. nsenter launches a shell inside the container with
> > PPID=0 as seen inside the container,
> > 2. systemd with PID=1 goes through the shutdown sequence,
> > issuing the equivalent(*) of
> >
> > kill(-1, SIGSTOP)
>
> This baffles me. I am not certain why someone whould send SIGSTOP
> when the want processes to exit. I'm not even saying it's wrong just
> saying that is odd.
This is how the killing spree generally worked on sysvinit systems too:
if we kill all remaining processes, then this might kill processes that
are children of others. Now, in general it is preferable getting the
SIGTERM/SIGKILL delivered to all these processes before possible SIGCHLD
signals for their dying children. Why? Simply to avoid log spew with
messages such as "Worker child process xyz died abnormally" generated by
the various system daemons.
By pausing all processes before delivering the SIGTERM/SIGKILL we can
ensure that if they are unpaused again the SIGTERM/SIGKILL is guaranteed
to be queued for each process and since on Linux lower-numbered signals
are guaranteed to be dispatched before higher-numbered signals (and
SIGKILL/SIGTERM is lower than SIGCHLD) we get the desired behaviour that
daemons exit quickly on SIGTERM/SIGKILL before handling the SIGCHLD.
Here's the code in sysvinit:
http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/killall5.c?revision=117&root=sysvinit&view=markup
Look for "kill(-1, SIGSTOP)".
Here's the code in systemd:
http://cgit.freedesktop.org/systemd/systemd/tree/src/core/killall.c#n185
Lennart
--
Lennart Poettering - Red Hat, Inc.
next prev parent reply other threads:[~2013-04-21 13:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20130417155727.GE19116@tango.0pointer.de>
2013-04-20 18:23 ` nsenter and SIGSTOP Zbigniew Jędrzejewski-Szmek
2013-04-20 22:27 ` [systemd-devel] " Eric W. Biederman
2013-04-21 13:21 ` Lennart Poettering [this message]
2013-04-21 14:45 ` Zbigniew Jędrzejewski-Szmek
2013-04-21 14:50 ` [not-for-applying PATCH] nsenter: do not self-suspend if child is suspended Zbigniew Jędrzejewski-Szmek
2013-04-21 16:18 ` nsenter and SIGSTOP Eric W. Biederman
2013-04-21 19:33 ` [systemd-devel] " Zbigniew Jędrzejewski-Szmek
2013-04-21 22:07 ` Eric W. Biederman
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=20130421132124.GA11663@tango.0pointer.de \
--to=lennart@poettering.net \
--cc=ebiederm@xmission.com \
--cc=systemd-devel@lists.freedesktop.org \
--cc=util-linux@vger.kernel.org \
--cc=zbyszek@in.waw.pl \
/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