[CRIU] Dumping Process - lxc-ls -f Problem

[Tycho Andersen]

On Sun, Jun 14, 2015 at 02:02:13PM +0100, Thouraya TH wrote:
> Hello all;
> 
> I have done two tests:  (criu 1.6)
> 
> 1- *Test 1:*
>    I have created a new container using:
>                      lxc-create -t ubuntu -n worker2 http_proxy=True
> 
>  *I have not installed any tool in this container.*
> 
>   lxc-checkpoint -s -D /tmp/dire -n worker2
>   lxc-checkpoint -r -D /tmp/dire -n worker2
> 
> root at localhost:~# lxc-ls -f
> NAME     STATE    IPV4       IPV6  GROUPS  AUTOSTART
> ----------------------------------------------------
> worker   STOPPED  -          -     -       NO
> *worker2*  RUNNING  10.0.3.48  -     -       NO
> 
> 2- *Test 2: *
> 
> lxc-start -n worker  (it is an old worker: i have installed many tools in
> this container, jdk, etc ......)
> root at localhost:/tmp# lxc-ls -f
> NAME     STATE    IPV4        IPV6  GROUPS  AUTOSTART
> -----------------------------------------------------
> worker   RUNNING  10.0.3.109  -     -       NO
> worker2  RUNNING  10.0.3.48   -     -       NO
> 
> lxc-checkpoint -s -D /tmp/direworker -n worker
> lxc-checkpoint -r -D /tmp/direworker -n worker
> 
> lxc-ls -f
> ^CTraceback (most recent call last):
>   File "/usr/bin/lxc-ls", line 432, in <module>
>     containers = get_containers(root=True)
>   File "/usr/bin/lxc-ls", line 261, in get_containers
>     if container.controllable:
> KeyboardInterrupt

This means that the restore failed and lxc-checkpoint didn't
understand that it failed, and is still waiting. I think we recently
fixed a bug (there is a patch about SIGCHLD) that will cause this not
to hang here.

> dump.log:
> Warn  (fsnotify.c:188): fsnotify:       Handle 800003:3c605 cannot be opened
> Warn  (fsnotify.c:188): fsnotify:       Handle 800003:4a4ba cannot be opened
> Warn  (arch/x86/crtools.c:132): Will restore 4271 with interrupted system
> call
> Warn  (arch/x86/crtools.c:132): Will restore 4454 with interrupted system
> call
> Warn  (arch/x86/crtools.c:132): Will restore 4455 with interrupted system
> call
> Warn  (arch/x86/crtools.c:132): Will restore 4460 with interrupted system
> call
> Warn  (arch/x86/crtools.c:132): Will restore 4461 with interrupted system
> call
> Warn  (arch/x86/crtools.c:132): Will restore 4463 with interrupted system
> call
> 
> restore.log:
> Warn  (cr-restore.c:1029): Set CLONE_PARENT | CLONE_NEWPID but it might
> cause restore problem,because not all kernels support such clone flags
> combinations!
> RTNETLINK answers: File exists
> RTNETLINK answers: File exists
> RTNETLINK answers: File exists
> 
> 
> Can you please explain to me what is the problem?  is it because of some
> tools installed in the container?

Do you have a way to reproduce this? I'm not sure what it means
exactly, perhaps Pavel can elaborate. However, it would be nice to
have a small testcase so I can try and fix it.

Thanks,

Tycho

> 
> Thanks a lot for help.
> Best regards.

> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu