[CRIU] Error CRIU restore because pid not matched

[Aris Setyawan]

Hi,

Is this feature has been implemented?
I can't find this on https://github.com/xemul/criu/issues

On 1/13/15, Pavel Emelyanov <xemul at parallels.com> wrote:
> On 01/13/2015 06:06 PM, Christopher Covington wrote:
>> On 01/13/2015 08:36 AM, Pavel Emelyanov wrote:
>>> On 01/12/2015 11:20 PM, Aris Setyawan wrote:
>>>>> 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.
>>>
>>> Ah, sorry for confusion. The option I mentioned would only help when
>>> the task you restore lives in the pid namespace and criu knows it. When
>>> you create new pidns and run criu in it, it would still think task is
>>> not in pidns and will just restore one, thus the --pidfile would write
>>> the virtual pid in it.
>>>
>>> So the current state of things is -- if tasks didn't live in pid
>>> namespace
>>> on dump, there's no handy way to restore them into new pidns and keep
>>> tracking their new pids.
>>>
>>> How about teaching CRIU restore tasks into the new pid namespace, even
>>> if the tasks weren't in it on dump? I was thinking about such a feature
>>> some time ago, but didn't think there would be a user for it.
>>>
>>> There's one thing with the feature I don't know what to do about, here
>>> it is. If we dump a task with pid, e.g. 42, then ask criu to restore one
>>> into a pid namespace, then criu would create a pidns, fork a task in it
>>> and restore one from images. This new task will have virtual pid being
>>> 42 and real one being some other value (written into pid file with the
>>> option). The question is -- who should be the init of the new pid
>>> namespace,
>>> i.e. the task with virtual pid 1?
>>
>> I might use the feature for restoring multiple copies of the same process.
>> I
>> don't really have a good reason for not using a namespace to begin
>> with--just
>> a little paranoia about it affecting performance and the probably unused
>> opportunity to reuse existing checkpoints. The following is what I settled
>> on
>> for no namespace when dumping, but using a namespace on restore.
>>
>> unshare -fp -- criu restore
>>
>> So a waiting/non-detaching criu process is pid 1.
>
> But this is ... nasty. Look, let's imagine some non-root process dies,
> then all its kids get reparented to init (i.e. -- criu), then one of the
> latter guys dies. CRIU's call to wait() exits and criu finishes thus
> bringing the whole namespace down.
>
>> This seems to work for
>> trivial tests, but I haven't really tried to stress it. A shortcoming I
>> noted
>> at one point was that --shell-job didn't work in this configuration and I
>> had
>> to launch the dumpee with setsid (this was with summer 2014 code, it
>> could
>> have been fixed too).
>
> :)
>
>> I had to start building util-linux-ng for my embedded style root
>> filesystems
>> in order to get unshare. If criu supported this mode of operation itself
>> (or
>> busybox got unshare or I switched to toybox which I think has unshare),
>> then
>> that'd be one less dependency for me to manage, but that's not bubbled to
>> the
>> top of my list yet.
>
> So we have one more reason for having this feature. That's great! I've
> added one onto the http://criu.org/Todo list.
>
> Thanks,
> Pavel
>
>
>