Package: lxc
Version:   1:1.0.6-6+deb8u1

Hi,

On a D8 host server with D7 containers upgraded to D8 with systemd -
following the instructions from the LXC Debian page.

  When I use lxc-stop command to cleanly stop a container, it waits,
times out and finally kills the container instead of issuing a clean
shutdown.

The pb does not happen on native D8 containers.

 
Here is a transcript:

  #lxc-stop -n mylxcbox


  This is what lxc-checkconfig returns: [all green]
===================================================
# lxc-checkconfig
Kernel configuration not found at /proc/config.gz; searching...
Kernel configuration found at /boot/config-3.16.0-4-amd64
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled

--- Control groups ---
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled
===================================================

  This is the configuration of the container [nothing really fancy here]
===================================================
cat /var/lib/lxc/mylxcbox/config
lxc.network.type = empty
lxc.rootfs = /var/lib/lxc/mylxcbox/rootfs

# Common configuration
lxc.include = /usr/share/lxc/config/debian.common.conf

# Container specific configuration
lxc.mount = /var/lib/lxc/mylxcbox/fstab
lxc.utsname = mylxcbox
lxc.arch = amd64
lxc.autodev = 1
lxc.kmsg = 0

lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = vbr0
lxc.network.ipv4 = 192.168.10.200/24
lxc.network.hwaddr = 00:1E:62:CH:NG:ME

# RAM
lxc.cgroup.memory.limit_in_bytes = 2G
===================================================

# lxc-monitor -n mylxcbox --logpriority=DEBUG
'mylxcbox' exited with status [0]
'mylxcbox' changed state to [STOPPING]
'mylxcbox' changed state to [STOPPED]


status 0 indicates the container was successfully stopped but it does it
after timing out:


I can verify this starting the container in non deamon mode [lxc-start
-n mylxcbox]
The services are not stopping, everything is killed after 60 seconds.


# time lxc-stop -n mylxcbox

real       1m0.146s
user       0m0.000s
sys       0m0.004s

It takes 60 seconds which means the container is killed after a 60
seconds timeout.
With the --nokill option added, the command times out but the container
remains up and running [ie: not killed].


As per manpage documentation:
DESCRIPTION
             lxc-stop reboots, cleanly shuts down, or kills all the
processes inside the container.
             By default, it will request a clean shutdown of the
container by sending   lxc.haltsig nal
            (defaults to SIGPWR) to the container's init process,
waiting up to 60 seconds for
             the container to exit, and then returning. If the container
fails to cleanly   exit   in
             60   seconds,   it   will be sent the lxc.stopsignal
(defaults to SIGKILL) to force it to
             shut down.



What could prevent lxc.haltsignal (defaults to SIGPWR) to reach an
upgraded D7 container to D8 with systemd ?

This is the solution/workaround I have found [took me 2 days] and which
will hopefully help you resolve the matter:

Changing the halt signal from the default (SIGPWR) to SIGRTMIN+4 by
adding the following configuration in the container config file:

allows me to shutdown the container with lxc-stop but also in a clean
manner with services being stopped as expected.

The two identified signals to request a clean shutdown [#1] and an
immediate halt[#2] for the D7 to D8 systemd containers are:

# modified signals for D7 containers upgraded to D8
lxc.haltsignal = SIGRTMIN+4       #1
lxc.stopsignal = SIGRTMIN+14    #2


  I am using Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u3
(2015-08-04) x86_64 GNU/Linux
The server and containers are frequently updated, all stable with
debian-security.

-- 

Cheers,

Nulld1g1t

Nulld1g1t Blog:
http://www.yourprog.com

Nulld1g1t Youtube channel:
https://www.youtube.com/user/nulld1g1t

Twitter:
https://twitter.com/nulld1g1t

Attachment: 0x6CF19A40.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to