[CRIU] [PATCH RFC v3 2/4] mem: Introduce image-proxy/image-cache & remote option

[Pavel Emelyanov]

On 09/18/2016 02:15 PM, Katerina Koukiou wrote:
> OK, with Cedric's help (cc'ed) fixed this one. Now, there is another I
> am struggling with.
> 
> The same error appears in many tests and goes like this:
> (I have to notice that this error is a bit random, meaning that does
> not always appear.)
> 
> ====================== Run zdtm/transition/unix_sock in h ======================
> Start test
> ./unix_sock --pidfile=unix_sock.pid --outfile=unix_sock.out
> --filename=unix_sock.test
> criu: no process found
> Adding image cache
> Cache pid = 10000
> Adding image proxy
> Proxy pid = 10003
> Run criu dump
> Run criu restore
> =[log]=> dump/zdtm/transition/unix_sock/24/1/restore.log
> ------------------------ grep Error ------------------------
> (00.024760)     24: Error (criu/cr-restore.c:1369): Pid 29 do not
> match expected 27
> (00.024979)     24: Error (criu/cr-restore.c:1130): 29 exited, status=1
> (00.025021) Error (criu/cr-restore.c:1999): Restoring FAILED.
> ------------------------ ERROR OVER ------------------------
> ############# Test zdtm/transition/unix_sock FAIL at CRIU restore ##############
> ##################################### FAIL #####################################
> 
> So, the problem here is that CRIU tries to forcefully get the right
> PID for the restored task by setting /proc/sys/kernel/ns_last_pid but
> the PID seems to be taken so it fails.

Yup.

> However, IIUC the restored task lives inside it's own PID namespace so
> I can't understand who is using the PIDs..

The restored task lives in its own PID namespace only if ns flavor is used.
The '-f ns' option to the zdtm.py. Otherwise restored task lives in the
same namespace as criu itself is.

> Is there a chance that criu-cache, criu-proxy processes as I invoke
> them in zdtm.py might take the right PID?
> 
> 
> Thanks for the prompt replies so far.
> Katerina
> 
> On Thu, Sep 15, 2016 at 11:02 AM, Pavel Emelyanov <xemul at virtuozzo.com> wrote:
>> On 09/11/2016 11:19 PM, Katerina Koukiou wrote:
>>> Hi,
>>>
>>> sorry for the delayed response. I adjusted your comments and decided
>>> to check the issue about the tests with namespaces later
>>> (https://lists.openvz.org/pipermail/criu/2016-August/030993.html) and
>>> send a fix in a separate commit. So for the time being I have this in zdtm.py:
>>>
>>> if opts['remote']:
>>>      run_flavs -= set(['ns', 'uns'])
>>>
>>> So I ran the zdtm tests with --remote option enabled and I hit an error like:
>>> === Run 3/260 ----------------
>>> Skipping zdtm/transition/netlink00 (manual run only)
>>>
>>> ====================== Run zdtm/transition/unix_sock in h ======================
>>> Start test
>>> ./unix_sock --pidfile=unix_sock.pid --outfile=unix_sock.out
>>> --filename=unix_sock.test
>>> criu: no process found
>>> Adding image cache
>>> Adding image proxy
>>> Run criu dump
>>> Run criu restore
>>> =[log]=> dump/zdtm/transition/unix_sock/24/1/restore.log
>>> ------------------------ grep Error ------------------------
>>> (00.021562)     24: Error (criu/sk-queue.c:48): Unable to change an
>>> image offset: Illegal seek
>>> (00.021631) Error (criu/cr-restore.c:1998): Restoring FAILED.
>>> ------------------------ ERROR OVER ------------------------
>>> ############# Test zdtm/transition/unix_sock FAIL at CRIU restore ##############
>>>
>>> I guess that's because we are not allowed to lseek on the socket. Any
>>> advice how to proceed with this?
>>
>> Yup, this is the lseek in the image. We used to have much more of these
>> in the old days and tried to get rid of them, but some are still there.
>>
>> The solution to this would be to read the data from image instead of
>> saving the file position and using this data later when required.
>>
>> -- Pavel
>>
> .
>