[CRIU] [PATCH] criu: Add exec-cmd option (v2)

[Deyan Doychev]

On 03/21/2014 09:32 AM, Andrew Vagin wrote:
> On Fri, Mar 21, 2014 at 08:40:41AM +0400, Pavel Emelyanov wrote:
>> > On 03/20/2014 08:40 PM, Christopher Covington wrote:
>>> > > 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?
>> > 
>> > Presumably they should. There're quite a few of them, I'm pretty sure
>> > that the main criu task only uses some service fds. By the way, what do
>> > you think about redirecting the logfd into 1 and 2 before exec()-ing?
> We can do this if a criu is executed as a sevice. If we execute
> 'criu restore' directly, we need to leave original descriptors.
>

We could do it when --restore-detached or --daemon are specified. This
way we will always redirect logfd into 1 and 2 when we leave the exec-ed
command running in background no matter if restore was started on
command line with -d or as a service.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvz.org/pipermail/criu/attachments/20140321/0b5a672d/attachment.sig>