[CRIU] Dumping of stream unix connection

[Artem Kuzmitskiy]

2015-06-05 16:36 GMT+03:00 Pavel Emelyanov <xemul at parallels.com>:

> 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.
>

Am I right understood that for socketpair's socket you propose using
"--ext-unix-sk $id (to be impl)" on dump and "inheriting (to be impl too)"
for restore?
And thx for explanation.

>
> -- Pavel
>
>


-- 
Best regards,
Artem Kuzmitskiy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20150605/96e24f36/attachment.html>