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

[Andrew Vagin]

On Fri, Mar 21, 2014 at 02:02:43PM +0400, Pavel Emelyanov wrote:
> On 03/21/2014 01:39 PM, Deyan Doychev wrote:
> > 
> > On 03/21/2014 11:14 AM, Pavel Emelyanov wrote:
> >>>> ...
> >>>>>>>>  		wait(NULL);
> >>>>>>>>  
> >>>>>>>>  	return 0;
> >>>>>>>> @@ -1600,6 +1600,9 @@ int cr_restore_tasks(void)
> >>>>>>>>  {
> >>>>>>>>  	int ret = -1;
> >>>>>>>>  
> >>>>>>>> +	if (opts.exec_cmd && opts.restore_detach && daemon(1, 0))
> >>>>>> In that case we will lose the ability to get error code from failed restore.
> >>>>>> Can we move the daemonizing to the very end of the restore procedure?
> >>>>
> >>>> We want the new process to be the father of the restored processes so
> >>>> the last place I see is right before the fork_with_pid(init); call in
> >>>> restore_root_task.
> >> Hm... Indeed. The daemon will create a child process and make the parent exit.
> >> Thus doing it after restore is not what we want :(
> >>
> >>>> Is this ok or do you have something else in mind?
> >> This is OK, but this brings a problem -- we lose the ability to check whether
> >> the restore failed or not.
> >>
> >> I think that making --exec-cmd work together with --restore-detached is quite
> >> tricky. We have to fork another task, make this child do restore, then execv()
> >> and then the parent should somehow check, that restore succeeded and exit. Or
> >> propagate the error code upwards.
> > 
> > I have an Idea of how to implement this check. We can use two signal
> > handlers in the parent process to catch CHLD and some other signal (USR1
> > seems OK). The child process can then send USR1 before calling execvp.
> > This way, receiving CHLD means the restore failure and USR1 - restore
> > success. However this has the following two problems:
> > 
> > 1. we cannot check the exec call
> 
> This is hardly required, since even if it fails, we cannot abort the
> restored tree.

Can we resume the restored tree before executing "exec-cmd".
My opinion is that we can't, because it may fail.

So maybe we need to fork a process for "exec-cmd" before restoring
processes.

criu restore
\
 criu restore (It will exec the cmd)
  \
   restore tree

This intermediate process does nothing while we are restoring processes.
If all processes are restored successfully, the first process gives a
signal to the second one to exec the cmd. And only if the cmd is
executed successfully, the first process resumes the restored tree.

In this case we will able to safely rollback if exec-cmd fails.

Does it sound reasonable?

Thanks,
Andrew