[CRIU] Error CRIU restore because pid not matched

[Pavel Emelyanov]

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?

Thanks,
Pavel