[CRIU] [PATCH] criu: Add exec-cmd option.

Christopher Covington cov at codeaurora.org
Thu Mar 20 07:00:23 PDT 2014


Hi Deyan,

On 03/20/2014 04:49 AM, Deyan Doychev wrote:
> Hi Christopher,

>>> diff --git a/crtools.c b/crtools.c
>>> index 047ac53..5591225 100644
>>> --- a/crtools.c
>>> +++ b/crtools.c

>>> +			pr_perror("Failed to exec command %s\n", opts.exec_cmd[0]);
>>> +			ret = 1;
>>> +		}
>>> +
>>> +		return ret != 0;
>> In my testing, a non-zero exit code wasn't propagated to the command line on
>> failure.
> 
> This is because the restore process becomes a daemon prior to restoring
> the dumped process when --exec-cmd is used.
> 
> I am not sure what the right action has to be if we fail to execute the
> command as we have already restored the processes.
> Should we consider this a full failure and if so - should we kill the
> processes we have restored?
> 
> Maybe the right thing  to do is daemonize only when -d was given instead
> of implying this option and always daemonizing. This way if -d is not
> specified we will exit with failure. But please advise what should we do
> with the restored processes?

What do the options look like in the LXC context?

For the perf use case killing would make retrying with a corrected exec-cmd
string slightly easier. Letting it run would be fine too, though, since it's
not that much work for the user to manually kill the process before retrying.

In my use case it's not acceptable to have an orphaned restored process
running in a separate PID namespace because it might alter system performance
undesirably. However, I can imagine other workloads where extra copies,
especially if they were sleeping, might not be much to worry about.

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