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

[Thouraya TH]

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

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?


Thanks a lot for help.
Best regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20150614/1472c161/attachment.html>