[CRIU] [PATCH] criu: Add exec-cmd option (v2)
Christopher Covington
cov at codeaurora.org
Thu Mar 20 09:40:01 PDT 2014
Hi Deyan,
On 03/20/2014 12:24 PM, Deyan Doychev wrote:
> From: Deyan Doychev <deyandoichev at gmail.com>
>
> The --exec-cmd option specifies a command that will be execvp()-ed on successful
> restore. This way the command specified here will become the parent process of
> the restored process tree.
>
> When this option is specified criu will fork to become a daemon before it starts
> restoring the processes. It also implies the -d option so waiting for the
> restored processes to finish is responsibility of the command specified here.
>
> This option will be used when restoring LinuX Containers and it seems helpful
> for perf or other use cases when restored processes must be supervised by a
> parent.
>
> Two directions were researched in order to integrate CRIU and LXC:
>
> 1. We tell to CRIU, that after restoring container is should execve()
> lxc properly explaining to it that there's a new container hanging
> around.
>
> 2. We make LXC set himself as child subreaper, then fork() criu and ask
> it to detach (-d) from restore container afterwards. Being a subreaper,
> it should get the container's init into his child list after it.
>
> The main reason for choosing the first option is that the second one can't work
> with the RPC service. If we call restore via the service then criu service will
> be the top-most task in the hierarchy and will not be able to reparent the
> restore trees to any other task in the system. Calling execve from service
> worker sub-task (and daemonizing it) should solve this.
Looks good overall. On the subject of file descriptor sharing, I wonder if all
of the CRIU open, dup, etc. calls should also be changed to use the O_CLOEXEC
flag?
Regards,
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
More information about the CRIU
mailing list