From: Daniel Lezcano <daniel.lezcano@free.fr>
To: Linux Containers <containers@lists.linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: [RFD] reboot / shutdown of a container
Date: Thu, 13 Jan 2011 17:34:35 +0100 [thread overview]
Message-ID: <4D2F299B.4000509@free.fr> (raw)
Hi all,
in the container implementation, we are facing the problem of a process
calling the sys_reboot syscall which of course makes the host to
poweroff/reboot.
If we drop the cap_sys_reboot capability, sys_reboot fails and the
container reach a shutdown state but the init process stay there, hence
the container becomes stuck waiting indefinitely the process '1' to exit.
The current implementation to make the shutdown / reboot of the
container to work is we watch, from a process outside of the container,
the <rootfs>/var/run/utmp file and check the runlevel each time the file
changes. When the 'reboot' or 'shutdown' level is detected, we wait for
a single remaining in the container and then we kill it.
That works but this is not efficient in case of a large number of
containers as we will have to watch a lot of utmp files. In addition,
the /var/run directory must *not* mounted as tmpfs in the distro.
Unfortunately, it is the default setup on most of the distros and tends
to generalize. That implies, the rootfs init's scripts must be modified
for the container when we put in place its rootfs and as /var/run is
supposed to be a tmpfs, most of the applications do not cleanup the
directory, so we need to add extra services to wipeout the files.
More problems arise when we do an upgrade of the distro inside the
container, because all the setup we made at creation time will be lost.
The upgrade overwrite the scripts, the fstab and so on.
We did what was possible to solve the problem from userspace but we
reach always a limit because there are different implementations of the
'init' process and the init's scripts differ from a distro to another
and the same with the versions.
We think this problem can only be solved from the kernel.
The idea was to send a signal SIGPWR to the parent of the pid '1' of the
pid namespace when the sys_reboot is called. Of course that won't occur
for the init pid namespace.
Does it make sense ?
Any idea is very welcome :)
-- Daniel
next reply other threads:[~2011-01-13 16:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-13 16:34 Daniel Lezcano [this message]
2011-01-13 20:09 ` [RFD] reboot / shutdown of a container Bruno Prémont
2011-01-13 21:32 ` Daniel Lezcano
2011-01-13 21:50 ` Bruno Prémont
2011-01-13 22:09 ` Daniel Lezcano
2011-01-14 23:11 ` Bruno Prémont
2011-01-15 7:54 ` Daniel Lezcano
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=4D2F299B.4000509@free.fr \
--to=daniel.lezcano@free.fr \
--cc=containers@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.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