[lxc-devel] [RFC][PATCH][lxc]: unfreeze while stopping

[Daniel Lezcano]

On 06/09/2010 07:29 PM, Sukadev Bhattiprolu wrote:
> Michel Normand [normand at 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<sukadev at 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