[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