[CRIU] [PATCH RFC v3 0/4] Process Migration using sockets

Mike Rapoport rppt at linux.vnet.ibm.com
Mon Aug 15 00:25:35 PDT 2016


On Wed, Aug 10, 2016 at 01:19:34PM +0000, Katerina Koukiou wrote:
> For the latter I faced some problems, so any help there would be appreciated.
> In particular:
> When running the test the first test passes and then the second fails, like this:
> The exact same happens with other test, not only with fork test.
> 
> ./zdtm.py run --test zdtm/transition/fork --remote
> === Run 1/1 ================
> ======================== Run zdtm/transition/fork in ns ========================
> Start test
> ./fork --pidfile=fork.pid --outfile=fork.out
> Adding image cache
> Adding image proxy
> Run criu dump
> Run criu restore
> =[log]=> dump/zdtm/transition/fork/7376/1/restore.log
> ------------------------ grep Error ------------------------
> (00.093454)      1: Error (criu/img-remote-proto.c:292): Unable to connect to local socket: /home/karen/criu/test/dump/zdtm/transition/fork/7376/1/image-cache.sock: No such file or directory
> (00.093463)      1: Error (criu/img-remote.c:75): Error opening local connection for seccomp.img:dump/zdtm/transition/fork/7376/1: No such file or directory
> ...
> 
> The strange thing is that by looking the restore.log for the second test, the image-cache.sock
> file seems to exist and read_remote_image_connection succeeds for some of the images.
> Moreover, image-cache.log does not indicate any error.
> Any idea what is wrong here?

It seems I had similar problem with the UNIX socket used by the lazy-pages
daemon.
If you are trying to create the socket or to call connect after the
namespaces are restored, the calling process sees different subset of
filesystem which does not have the UNIX socket special file.


> Please ask to send the full logs if needed.
> 
> Last, inside zdtm.py I need to force kill image-cache and image-proxy before continuing
> to the next test.
> I have used "killall -9 criu" as at that point only these criu processes can be
> childs of the python script. However it's bad practice, so feel free to propose
> another way to get rid of the two processes.
> 
> Regards,
> Katerina
> 
> 
> Katerina Koukiou (4):
>   mem: implement image proxy/image cache
>   mem: Introduce image-proxy/image-cache & remote option
>   test: Add testcases for image-proxy/image-cache
>   zdtm: Add testing for --remote option
> 
>  criu/Makefile.crtools           |   4 +
>  criu/cr-dump.c                  |  17 +
>  criu/crtools.c                  |  30 +-
>  criu/image-desc.c               |   4 +-
>  criu/image.c                    |  28 +-
>  criu/img-cache.c                | 170 ++++++++++
>  criu/img-proxy.c                | 119 +++++++
>  criu/img-remote-proto.c         | 697 ++++++++++++++++++++++++++++++++++++++++
>  criu/img-remote.c               | 278 ++++++++++++++++
>  criu/include/cr_options.h       |   3 +
>  criu/include/image.h            |   1 +
>  criu/include/img-remote-proto.h |  84 +++++
>  criu/include/img-remote.h       |  79 +++++
>  criu/include/protobuf-desc.h    |   4 +
>  criu/page-xfer.c                |  26 +-
>  criu/pagemap.c                  |  53 ++-
>  criu/protobuf-desc.c            |   1 +
>  images/Makefile                 |   1 +
>  images/remote-image.proto       |  20 ++
>  test/proxy-cache/Makefile       |  29 ++
>  test/proxy-cache/loop.sh        |   8 +
>  test/proxy-cache/run.sh         | 106 ++++++
>  test/zdtm.py                    |  36 ++-
>  23 files changed, 1773 insertions(+), 25 deletions(-)
>  create mode 100644 criu/img-cache.c
>  create mode 100644 criu/img-proxy.c
>  create mode 100644 criu/img-remote-proto.c
>  create mode 100644 criu/img-remote.c
>  create mode 100644 criu/include/img-remote-proto.h
>  create mode 100644 criu/include/img-remote.h
>  create mode 100644 images/remote-image.proto
>  create mode 100644 test/proxy-cache/Makefile
>  create mode 100755 test/proxy-cache/loop.sh
>  create mode 100755 test/proxy-cache/run.sh
> 
> -- 
> 2.7.3
> 
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu
> 



More information about the CRIU mailing list