[CRIU] Error CRIU restore because pid not matched

Pavel Emelyanov xemul at parallels.com
Mon Jan 12 02:31:21 PST 2015


On 01/05/2015 06:36 AM, Aris Setyawan wrote:
> Hi Chris,
> 
>> For simple situations you may be able to start a script in the new namespace that restores, waits, and dumps again
> 
> Yes this is absolutely will work, If I use criu C API, but I currently
> use criu command-line (then call it frm PHP script).
> 
> The problem I faced is, because I use separated command line to
> restore and dump process (a web service process).
> Using, "unshare" command, I successfully run restore process in new
> namespace, to avoid PID mismatch. If I detach criu from my own process
> (-d option), then the new namespace inherited from criu, will be
> destroyed.
> If I'm not using -d option, then I can dump the process again.

Do I get you right, when you restore the processes in pid namespace
you need to know its new PID in the initial one to  dump it again
some time soon?

If yes, then the --pidfile option would help you. When used on restore
it makes CRIU write the real pid of the root task restored into a file
specified.

> Btw,
> I think, the sequences of "restore-process-dump" can be done with criu
> service + RPC.
> Is that possible? 

Yes. You should start the service, then feed RPC commands to it. You
can even make the so called "self-dump" with it, when the process asks
service to dump itself. In this case you don't need to know exact pid
values too.

> If yes, I can start criu service using "unshare -p
> --fork --mount-proc" command.
> 
> On 1/3/15, Christopher Covington <cov at codeaurora.org> wrote:
>> Hi Aris,
>>
>> On 12/31/2014 06:20 PM, Aris Setyawan wrote:
>>>> P.S. I'd appreciate if any discussion about CRIU happens with the
>>>> mailing
>>>> list in Cc. My responsiveness throughput is limited :) but on the
>>>> mailing
>>>> list there are quite a lot of other people that can help.
>>>
>>> Ok.
>>>
>>>> [1] http://criu.org/When_C/R_fails
>>>
>>> Ok, I successfully restore it using unshare command, after dump it
>>> (test.sh process):
>>>
>>> 	criu dump -t 422439 --images-dir /tmp/test --shell-job
>>> 	unshare -p --fork --mount-proc criu restore --images-dir /tmp/test
>>> --shell-job
>>>
>>> And the test.sh process, run as a child process (this is because we
>>> can not running restore with -d option):
>>>
>>> 	$ ps ax | grep test
>>> 	 422516 pts/0    S      0:00 /path/unshare -p --fork --mount-proc
>>> /path/criu restore --images-dir /tmp/test --shell-job
>>> 	 422517 pts/0    S      0:00 /path/criu restore --images-dir
>>> /tmp/test --shell-job
>>> 	 422518 pts/0    S      0:15 /bin/sh ./test.sh
>>>
>>> In my use case, I need to dump test.sh process again (and it's state)
>>> and then restore it again, then doing a computation. And then dump it
>>> again.
>>>
>>> New problem, come. How I can dump the process again?
>>
>> For simple situations you may be able to start a script in the new
>> namespace
>> that restores, waits, and dumps again. If that won't work, you may want to
>> look into using the setns system call to enter the namespace.
>>
>> http://man7.org/linux/man-pages/man2/setns.2.html
>>
>> A brief look at the --namespaces option and the calls to switch_ns() [which
>> calls setns()] makes me think CRIU currently does not have such
>> functionality,
>> but I may be misinterpreting or overlooking something.
>>
>> Chris
>>
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>>
> .
> 



More information about the CRIU mailing list