Hi, current lxc-info is used in lxc->stop() to get a container's init pid: init_pid=$(lxc-info -n ${CONTAINER} --pid | cut -d: -f 2) and lxc-info when applied to stopped container gives a shining pid: -1 and this is bug i think but hey! shouldn't init scripts to mitigate issues like this? i mean current code just doing kill -INT ${init_pid} and with pid=-1 effectively kill the whole system :) Reproducible: Always
i'm sorry, i forgot the steps to reproduce this bug, i think something like: (create somewhat-container) # /etc/init.d/lxc.somewhat-container start # lxc-stop -n somewhat-container # etc/init.d/lxc.somewhat-container stop will be enough
So steps to reproduce involve: 1) Using the init.d script to start the service. 2) Killing the service by bypassing the init.d script. 3) Using the init.d script to stop the service. ?
if ! [ -d ${cgroupmount}/${CONTAINER} ]; then ewarn "${CONTAINER} doesn't seem to be started." return 0 fi This should make it impossible for the init script to call lxc-info on a stopped container. Looks like something's fishy...
Well, whether you have an issue or not the init script was made safer, even though I don't like the idea that it would reach that point with a stopped container.
(In reply to comment #3) > if ! [ -d ${cgroupmount}/${CONTAINER} ]; then > ewarn "${CONTAINER} doesn't seem to be started." > return 0 > fi > > This should make it impossible for the init script to call lxc-info on a > stopped container. Looks like something's fishy... You are right, i missing it. So step 2 should be # lxc-stop -n somewhat-container # mkdir ${cgroupmount}/somewhat-container i mean even in this case init script shouldn't send sigint to enire system, nop? in fact i've got this today when my shiny new container doesn't start properly and i stop it. (It's very impressive to see somthig like 'reseting connection' in the ssh console after lxc stop :)) You're right, it's fishy. Seems like i've look deeper into lxc code...
As I said I made it safer, so it is fixed.
Hi, Just wanted to comment -- I can run into this bug on -r2 with the following behavior: In container: reboot (it won't come back up) Outside container: /etc/init.d/lxc.[container] stop Updating to -r3, which says it solves this, but thought maybe that would help/be of interest.
if [ "${init_pid}" = "-1" ]; then ewarn "${CONTAINER} doesn't seem to be running." return 0 fi if [ "${init_pid}" = "-1" ] -- looks like a perl-style typo
Hello, Isn't there a problem with files/lxc.initd on line 132? 132 if [ -n "${missingprocs}" ]; then 133 ewarn "Something failed to properly shut down in ${CONTAINER}" 134 fi => this will never be true, because ${missingprocs} has been patch'ed out...
(In reply to comment #8) > if [ "${init_pid}" = "-1" ]; then > ewarn "${CONTAINER} doesn't seem to be running." > return 0 > fi > > if [ "${init_pid}" = "-1" ] -- looks like a perl-style typo ${init_pid} contains " -1", but is compared with "-1". Example output: $ lxc-info -n centos --pid lxc-info: 'centos' is not running pid: -1 app-emulation/lxc-0.7.5-r3 BTW, this works: init_pid=$(lxc-info -n ${CONTAINER} --pid| awk 'BEGIN { $IFS=":" } { print $2 }') Perhaps, better solution exists.