[CRIU] Error CRIU restore because pid not matched

[Aris Setyawan]

I have did a benchmark. The result is that around 50% of my restore
command, failed with error "pid not matched". It is a high number. Is
this normal?

I ran restore command under non root user.

> One way to work around this is to unshare the pid namespace with
> unshare -p, then call restore. But in this case you may suffer from
> /proc being the proc from former pid namespace, not the new one. This,
> in turn, can be solved by unsharing the mount namespace too and
> re-mounting the /proc.

I have tried this, but not work.
Everytime I restore using "unshare -pid restore", the new PID is
always "1". That, of course, will be miss-match.

On 10/25/14, Pavel Emelyanov <xemul at parallels.com> wrote:
> On 10/24/2014 08:08 PM, Aris Setyawan wrote:
>>> This means, that pid 1813, with which the restored task wants to live,
>>> is already busy.
>>
>> Is this mean, that pid already used by another process?
>
> Yes
>
>>> This option was obsoleted some time ago, sorry. Now CRIU detects
>>> and creates the namespaces itself.
>>
>> I have read the code, and it will "always" raise error, if mismatch
>> happened.
>
> Exactly.
>
>> How to prevent this?
>> So it can't be fixed?
>
> 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.
>
> One way to work around this is to unshare the pid namespace with
> unshare -p, then call restore. But in this case you may suffer from
> /proc being the proc from former pid namespace, not the new one. This,
> in turn, can be solved by unsharing the mount namespace too and
> re-mounting the /proc.
>
> The most viable solution for this type of usecases is to checkpoint
> and restore tasks living in namespaces from the very beginning, i.e.
> start them in this or that form of container.
>
>
> Thanks,
> Pavel
>
>