[CRIU] Dumping of stream unix connection

[Pavel Emelyanov]

On 06/05/2015 04:25 PM, Artem Kuzmitskiy wrote:
> 
> 
> 2015-06-04 23:30 GMT+03:00 Pavel Emelyanov <xemul at parallels.com <mailto:xemul at parallels.com>>:
> 
>     On 06/04/2015 07:35 PM, Artem Kuzmitskiy wrote:
>     >
>     >
>     > 2015-06-04 16:42 GMT+03:00 Pavel Emelyanov <xemul at parallels.com <mailto:xemul at parallels.com> <mailto:xemul at parallels.com <mailto:xemul at parallels.com>>>:
>     >
>     >     > Hi all,
>     >     >
>     >     > We're returned back at this problem..
>     >
>     >     Cool :)
>     >
>     >     >>     >     > The usage scenario is following: I'm having a parent process and a child processes bidirectonal communicating
>     >     >>     >     > via stream Unix socket. The idea is to dump child process when it's not needed and to restore it
>     >     >>     >     > again later
>     >     >
>     >     > This task still need for us and we did some test with upstream version of CRIU.
>     >     > Code of test stub here -> http://pastebin.com/tLnRdE3K
>     >     > CRIU called with next params:
>     >     > for dump -> ${CRIU_bin} dump -vvvv -o <PID>.log -D ${DIR} -t <PID> -d --shell-job --ext-unix-sk
>     >     > for restore -> ${CRIU_bin} restore -vvvv -o <PID>.log -D ${DIR}  -d --shell-job --ext-unix-sk
>     >     >
>     >     > Test case: child write in a unix sock, parent read from unix sock.
>     >     > Child proccess dumped&restored, but
>     >     >  - only if we don't close sockets after fork (sock[0] in child and sock[1] in parent respectively) otherwise restore process failed
>     >
>     >     Can you share the restore logs?
>     >
>     >
>     > yes sure:
>     > test stub -> http://pastebin.com/iBuQy0CL
>     > dump log -> http://pastebin.com/9ysvQ69m
>     > restorel log ->  http://pastebin.com/HR459Diu
> 
>     Heh :) This is external dgram socket w/o a name. Can happen if it's a socketpair, but
>     criu errorneously tries to connect() them back. Bug in CRIU, thanks!
> 
>  
> yep.....also we tested same scenario but using named unix socket for IPC with SOCK_DGRAM param (test stub code -> http://pastebin.com/QRYrV3LW) and it works fine.
> If sockets has SOCK_SEQPACKET or SOCK_STREAM dump failed(sk-unix.c:546 ) and it's current limitation of CRIU.

Yes. The justification is simple -- the server will notice EOF on the socket if we dump it and we
may not be able to connect one back on restore.

However, I'm OK if someone sends a patch that extends the --ext-unix-sk option with the following
semantics:

- On dump --ext-unix-sk $id says that the stream/seqpacket socket $id is OK to be disconnected
- On restore --ext-unix-sk $id:$path says that socket $id should be connect()-ed to $path. The
  $path may be absent meaning that the connction should go to the path seen on dump.

Note, that this won't work for socketpairs() as they are name-less and cannot be reconnect-ed
back. For those only inheriting will work.

-- Pavel