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

[Katerina Koukiou]

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.
However, IIUC the restored task lives inside it's own PID namespace so
I can't understand who is using the PIDs..
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
>