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

Matt Helsley matthltc at us.ibm.com
Wed Jun 9 13:39:01 UTC 2010


On Tue, Jun 08, 2010 at 07:07:04PM -0700, Sukadev Bhattiprolu wrote:
> 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).
> 
> (lxc-stop waits for the container to exit and close the socket but since
> the container is frozen, lxc-stop will block).
> 
> [Dan Smith pointed this out while testing out-of-tree lxc-checkpoint/restart]

Yup. Because it's frozen pending signals aren't delivered until after
the task is thawed.

Acked-by: Matt Helsley <matthltc at us.ibm.com>

> 
> Signed-off-by: Sukadev Bhattiprolu <sukadev at linux.vnet.ibm.com>
> ---
>  src/lxc/stop.c |   10 ++++++++--
>  1 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/src/lxc/stop.c b/src/lxc/stop.c
> index b751af5..f441e46 100644
> --- a/src/lxc/stop.c
> +++ b/src/lxc/stop.c
> @@ -83,8 +83,14 @@ extern int lxc_stop_callback(int fd, struct lxc_request *request,
>  	int ret;
> 
>  	answer.ret = kill(handler->pid, SIGKILL);
> -	if (!answer.ret)
> -		return 0;
> +	if (!answer.ret) {
> +		ret = lxc_unfreeze(handler->name);
> +		if (!ret)
> +			return 0;
> +
> +		ERROR("failed to unfreeze container");
> +		answer.ret = ret;
> +	}
> 
>  	ret = send(fd, &answer, sizeof(answer), 0);
>  	if (ret < 0) {
> -- 
> 1.6.6.1
> 




More information about the lxc-devel mailing list