On 06/09/2010 07:29 PM, Sukadev Bhattiprolu wrote: > 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).
Suka, Can you resend your patch as it is without the RFC prefix and add a note to the man page ? Thanks -- Daniel ------------------------------------------------------------------------------ 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
