[systemd-devel] Restarting from inside systemd-nspawn container results in deactivation

[Djalal Harouni]

On Mon, Jun 02, 2014 at 10:04:43PM +1000, Jonathan Liu wrote:
> On 2/06/2014 8:51 PM, Djalal Harouni wrote:
> >On Mon, Jun 02, 2014 at 11:47:39AM +1000, Jonathan Liu wrote:
> >>Hi,
> >>
> >>I am using systemd 212 on Arch Linux 64-bit with the following patch applied:
> >>http://cgit.freedesktop.org/systemd/systemd/commit/?id=d8e40d62ab871a87fde421c4b246bb45bc3cbe2d
> >It would be easy for us if you could test the latest systemd 213
> Ok, testing with systemd 213.
> >
> >>I have systemd-nspawn at mycontainer service enabled and started for my container.
> >>If I SSH into the container and run the reboot command, the container
> >>reboots successfully and I can SSH into it again.
> >>However if I run systemctl status systemd-nspawn at mycontainer on the
> >>host, I notice the Active status changes from "Active: active
> >>(running)" to "Active: deactivating (stop-sigterm)". After about a
> >>minute and a half, systemd kills the container and my SSH connection
> >>is lost.
> >And without the above patch ? (perhaps some cleaning races/left jobs...)
> Behaves the same without the above patch.
> >
> >
> >>Any ideas on how to proceed with fixing it so the container isn't
> >>killed when reboot is issued inside the container?
> >If you are able to disable the service, try running it manually:
> ># systemd-nspawn -bD /path/to/container
> >
> >Taken from: https://wiki.archlinux.org/index.php/Arch_systemd_container
> >
> >Then do a reboot/restart from the container and see!
> Works fine if I am running systemd-nspawn directly. It seems to be
> related to the service logic.
Indeed, thank you for the logs!

So from a quick look: it seems that systemd after reboot detects that
systemd-nspawn at mycontainer.service timed out, which then the second
SIGKILL on the *wrong* systemd-nspawn at mycontainer.service

-- 
Djalal Harouni
http://opendz.org