[CRIU] HA: alternate implementation of --ext-unix-sk

[Tycho Andersen]

On Tue, Nov 10, 2015 at 07:21:46AM +0100, Artem Kuzmitskiy wrote:
> Hi Tycho,
> 
> As a whole I agreed with you, but it's was done for next reason, currently we can use only "inherit" functionality for restore and "restorer" should make a new IPC channels on user code side . 
> It's means that restorer should control how many channels he has and how many new channels he should make for successful restoration.

If I understand correctly, you're describing a case where there is
some connection state that needs to be negotiated at the application
layer before it is really "restored". That is, there is more than just
reconnecting the sockets required.

But suppose the connection is stateless (or the general case, where
the caller is some container runtime and probably doesn't know
anything more about the connection than criu would). The only way
(that I can think of) to restore such cases in the runtime is to do
what I described. Of course it would be unsafe in general, but
enabling it for specific known-ok paths should be ok, I think.

Tycho

> Best regards,
> Artem Kuzmitskiy
> LG Russia R&D Lab, St.-Petersburg
> ________________________________________
> От: Tycho Andersen [tycho.andersen at canonical.com]
> Отправлено: 10 ноября 2015 г. 3:00
> Кому: Artem Kuzmitskiy/Russia R&D Lab Web Team Web 3 Part(artem.kuzmitskiy at lge.com); criu at openvz.org
> Тема: alternate implementation of --ext-unix-sk
> 
> Hi all,
> 
> in 79fd764ae6c4eabcc12da0159e4ad96b02431df0 and
> http://criu.org/External_UNIX_socket#What_to_do_with_socketpair.28.29-s.3F
> 
> an implementation of --ext-unix-sk is described that you pass the
> inode of the external socket. One way to find this inode is to look
> for a specific path in /proc/net/unix inside the container's netns.
> 
> Is there any reason we can't just pass --ext-unix-sk=/foo/bar and have
> every socket connected to this be dumpable and restorable (by being
> reconnected as described on the wiki)? This would be less work (and
> more intiutive, I think) for most than passing the inode number, but I
> might be missing something.
> 
> Thanks,
> 
> Tycho