The problem is lxc has to watch the jail's utmp file to guess when it
wants to halt, because Linux kernels before version 3.4 does not
provide any function to reboot or halt a container from inside. It has
leaded to a dirty hack in lxc-utils that failed now.
First problem is the overlaid /run;
Package: sysvinit
Version: 2.88dsf-41
Followup-For: Bug #706676
I just discovered that not dropping the ``sys_boot`` capability from a
container fixes the issue, plus it allows the container to properly reboot
(instead of launching a bare shell in the case of Debian containers).
So maybe it was
Package: sysvinit
Version: 2.88dsf-41
Followup-For: Bug #706676
The bug still exists with kernel 3.9-1-amd64 (3.9.5-1).
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.9-1-amd64 (SMP w/2 CPU
Package: sysvinit
Version: 2.88dsf-41
Followup-For: Bug #706676
In my case the container terminates correctly when using kernel 3.2.0-4, but
it needs the lxc-stop with kernel 3.8-2. The rest of software is the same.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT
I am affected by this problem, too. lxc-ps shows, that init is
the only process kept running in the container.
Using Squeeze (sysvinit 2.88dsf-13.1+squeeze1) there is no such
problem.
Harri
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe.
Package: sysvinit
Version: 2.88dsf-41
Severity: important
It seems that init doesn't handle properly SIGPWR inside LXC container,
even after applying a workarround found at :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695568#15
'lxc-shutdown -n container' halts gracefully a container but
6 matches
Mail list logo
