Michel Normand [norm...@fr.ibm.com] wrote: | Le mardi 08 juin 2010 à 19:07 -0700, Sukadev Bhattiprolu a écrit : | > I am not too sure, but if user wants to stop a container is there a | > reason not to implicitly unfreeze the container and stop ? | > | > --- | > From: Sukadev Bhattiprolu <suka...@linux.vnet.ibm.com> | > Date: Tue, 8 Jun 2010 18:42:00 -0700 | > Subject: [PATCH 1/1]: unfreeze while stopping container | > | > When a container is being stopped, it must also be unfrozen after posting | > the SIGKILL. Otherwise if the container is frozen when the SIGKILL is posted, | > the SIGKILL will remain pending and the lxc-stop command will block until | > lxc-unfreeze is explicitly called). | | For me the lxc-start/lxc-stop and | lxc-freeze/lxc-unfreeze are two sets of commands | that should not be mixed. | | If the container was previously frozen by a lxc-freeze | then the user has to issue a lxc-unfreeze before to issue the lxc-stop.
Ok, if that is the design, then we should change the lxc_stop_callback() to send an answer even on success ? Currently on successful stop it expects the socket to close, which will unblock the waiting lxc_stop() caller. But if the container is frozen the lxc_stop() caller waits indefinitely. Its not an issue for the lxc-stop command, but is an issue when lxc-checkpoint calls lxc_stop() (in response to the --kill option). Sukadev ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
