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

Deyan Doychev deyan at 1h.com
Fri Mar 21 01:57:47 PDT 2014


Hi Pavel,

On 03/20/2014 08:38 PM, Pavel Emelyanov wrote:
> On 03/20/2014 08:24 PM, Deyan Doychev wrote:
>> From: Deyan Doychev <deyandoichev at gmail.com>
>> ...
>> --- a/cr-restore.c
>> +++ b/cr-restore.c
>> @@ -1552,7 +1552,7 @@ static int restore_root_task(struct pstree_item *init)
>>  
>>  	write_stats(RESTORE_STATS);
>>  
>> -	if (!opts.restore_detach)
>> +	if (!opts.restore_detach && !opts.exec_cmd)
> I feel that I'm missing something, but why is the check for
> !opts.exec_cmd is needed here?

This code waits for the restored task to finish. Thus if we don't skip
the wait call, we will exec after the restored task has already finished
which is not intended. The exec-ed program should wait for the child
when using --exec. That's why we need this check.

> ...
>>  		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.

Is this ok or do you have something else in mind?

>> @@ -37,6 +37,7 @@ message criu_opts {
>>  
>>  	optional uint32			cpu_cap		= 20 [default = 0xffffffff];
>>  	optional bool			force_irmap	= 21;
>> +	optional string			exec_cmd	= 22;
> Maybe it's better to make this field repeated to allow for spaces in
> arguments and to simplify the parsing (no strtoks would be required)?

Sure, will resubmit.

Thanks,
Deyan

-------------- 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/90f15ad0/attachment.sig>


More information about the CRIU mailing list