[CRIU] Error CRIU restore because pid not matched

Aris Setyawan aris.sety at gmail.com
Mon Jan 12 12:20:27 PST 2015


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

Yes.

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

But, you have said in earlier comment:

"In theory we can let process live with whatever PID kernel allocates
for it, but our knowledge of glibc says that most likely there will
be BUGs."

Is that "--pidfile" option still working? I just want to workaround
with PID mismatch error.

On 1/12/15, Pavel Emelyanov <xemul at parallels.com> wrote:
> 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