Bug#768827: systemd: issues with systemd in a lxc container

[Cameron Norman]

Hello Michael,

On Sun, 09 Nov 2014 16:22:36 +0100 Michael Biebl <biebl at debian.org> 
wrote:
 > Control: retitle -1 issues with systemd in a lxc container
 >
 > Am 09.11.2014 um 16:11 schrieb Ritesh Raj Sarraf:
 > > If I switch the init sysvinit-core in the LXC container, then the
 > > problem goes away. Therefore I've come to the conclusion that the 
bug
 > > lies with systemd.
 >
 > I don't think the lxc maintainers currently support systemd in a
 > container [1].
 > Afair, this is something which needs to be addressed in lxc, though, 
and
 > not not systemd. That said, if there is something we can do in the
 > systemd package, to make it work (better) in lxc, please let us know.

There are a few things. Linking sigpwr.target to halt.target would make 
lxc-stop work *cleanly* OOTB. Also the patch to getty at .service shown 
here would help: 
https://wiki.archlinux.org/index.php/Linux_Containers#lxc-console_does_not_provide_a_login_prompt

The big one would be to pop up a prompt on first install of 
systemd-sysv while in an lxc container (similar to the /etc/inittab 
checking and associated message that is planned I think) telling the 
user that the host's version of LXC must be 0.8 or greater (available 
in squeeze-backports and wheezy), and the configuration for the 
container (a file on the host) needs to contain the lines `lxc.kmsg = 
0` and `lxc.autodev = 1`.

That last one is difficult because the host may not support those 
options (older than 0.8 LXC version), we can not adjust them ourselves 
from inside the container, and the container becomes unbootable if they 
are not set correctly (I think journald uses 100% CPU if lxc.kmsg is 1 
instead of 0).

Also apparently udev should not run in containers. Do you think we 
should have something with ConditionVirtualization!=container or 
whatever in the udev service file?

The lxc debian template tries to do all of this (including masking 
udev.service and systemd-udev.service), but it can only act on newly 
created containers so upgraded ones are left high and dry.

Cheers,
--
Cameron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20141211/9d45a387/attachment-0001.html>