hi there, i am the maintainer of gentoo-lxc, a script that generates a gentoo guest for lxc-capable hosts. this is all 'REPORTEDLY', i haven't tested it myself. however, after deploying the apparent fix, nobody has complained, which suggests that this is reasonable. therefore, i figured i'd pass it along for your consideration. basically, users report that guests do not shut down properly when sent SIGPWR, however this may be fixed as follows: https://github.com/globalcitizen/lxc-gentoo/commit/3a1608147082f75bbff87178d349a5e941aa5933 original report here: https://github.com/globalcitizen/lxc-gentoo/issues/60 Reproducible: Always Steps to Reproduce: 1. shut down a gentoo-powered lxc container Actual Results: no shutdown Expected Results: clean shutdown
See additional info regarding LXC behaviors at https://github.com/globalcitizen/lxc-gentoo/issues/60
Dear Walter, I'm currently updating an about one year old Gentoo installation and just run into the same issue: With an upgraded container image, lxc-start will not terminate anymore. At the container image itself - it's just a plain basic image with no further services installed -- all works fine and on shutdown the init process will stop at the final message (INIT: no more processes left in this runlevel). But lxc-start isn't able to detect this. By comparing with the not-updated image, in the log of lxc-start the're are no lxc-utmp messages related to the change of init runlevel anymore. From this, lxc-start can't see if the client's init have finished and will not terminate. I'll try to trace down what have changed. BTW: I may confirm the fix to add a powerfail line to /etc/inittab as working -- i'm using this in my installation to provide an external shutdown of a container, too. But it's not the core of the current problem, which seems to be introduced by the current openrc or something related. with greetings Guido
Verified as still affecting openrc-0.12.4. I suspect this may be related to a missing capability in the container. What code does OpenRC call after there are no processes left in the container? My guess is that it makes some kind of system call to the kernel which is normally virtualized for LXC guests by redirecting the issued syscall to trigger a container shutdown for the guest, rather than the shutdown of the host system. By being paranoid, however, and running containers with a largely reduced set of capabilities, the call is never successfully made by the guest so the kernel never receives the signal to shut down. That's just a theory, though. If true, the fix would be to segregate the shutdown (and possibly closely related) signals from other system calls within the overall kernel capabilities model.
To clarify there were actually 2 issues here: (1) is already fixed (externally initiated clean shutdowns are now possible) by adding a sigpwr responder to inittaib (2) not yet fixed ('shutdown -h now' simply runs init to 'no processes left in this runlevel' then sits forever)
Why did you close that? Has this been fixed somehow?
