[CRIU] Restore error

[Pavel Emelyanov]

On 02/29/2016 09:21 PM, Gabriel Southern wrote:
> 
> 
>     Ah! :) This info is really helpful. You're re-using the netns for all the restores (the
>     "NS mask to use 2c020000" line in the log). Can you help us understand what's the netns
>     trick your playing?
> 
>     And the bug is that criu creates unix sockets (that help to restore files) with not unique
>     enough names. The fix would be to tune open_transport_fd() routine and add some "salt" to
>     the call to transport_name_gen() that generates unix socket name, but w/o proper understanding
>     of what's going on with netns we can come to suboptimal solution.
> 
> 
> Thanks for the explanation.  As to what I'm doing I'm creating Docker containers using the command:
> 
> docker create --net=host --security-opt seccomp:unconfined <docker image>

I see. Well, the --net=host makes the container share the netns with host, so this
explains why we hit sockets' names conflict.

So the solution would be to provide a better (unique) name for the socket in the routine
that I've mentioned earlier.

-- Pavel

> Then when I restore the checkpoints I'm using the command:
> 
> docker restore --force --image-dir=<path to image> <docker container>
> 
> I'm not sure exactly what low-level commands this translates to.  I'll try to take a look later.  Some of the people who worked on the Docker CR stuff might be following this list and have a better idea.  
> 
> Also I've been using the --net=host option as a workaround for the checkpoint/restore in Docker not having networking fully working when I started using it.  But I read that there was some progress with getting networking working with Docker CR (https://github.com/boucher/docker/releases/tag/v1.10_2-16-16-experimental).  I haven't tried with the steps described there yet, but I'm planning to now to see if that solves the issue I'm having or not.  I'll update the list later to say whether or not it works.
> 
> -Gabriel
>