Summary: | app-emulation/lxc-0.7.5-r2: init script: host process mass killing | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alexander Y. Fomichev <git.user> |
Component: | New packages | Assignee: | Diego Elio Pettenò (RETIRED) <flameeyes> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | bug, dev-zero, lispnik, virtualization |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Alexander Y. Fomichev
2011-10-19 13:26:04 UTC
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. |