<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 03/27/2015 07:27 PM, Anatoly Baranov wrote:<br>
><br>
> 2015-03-25 17:08 GMT+03:00 Pavel Emelyanov <<a href="mailto:xemul@parallels.com" target="_blank">xemul@parallels.com</a> <mailto:<a href="mailto:xemul@parallels.com" target="_blank">xemul@parallels.com</a>>>:<br>
><br>
> On 03/25/2015 05:00 PM, Anatoly Baranov wrote:<br>
> ><br>
> > 2015-03-25 15:57 GMT+03:00 Pavel Emelyanov <<a href="mailto:xemul@parallels.com" target="_blank">xemul@parallels.com</a> <mailto:<a href="mailto:xemul@parallels.com" target="_blank">xemul@parallels.com</a>> <mailto:<a href="mailto:xemul@parallels.com" target="_blank">xemul@parallels.com</a> <mailto:<a href="mailto:xemul@parallels.com" target="_blank">xemul@parallels.com</a>>>>:<br>
> ><br>
> > On 03/25/2015 01:46 PM, Анатолий Баранов wrote:<br>
> > > Hi all,<br>
> > > I found that there are troubles with dumping of stream Unix connection: when I'm trying to<br>
> > > checkpoint it, I'm receiving "Can't dump half of stream Unix connection" message.<br>
> > > I've found this thread: <a href="http://lists.openvz.org/pipermail/criu/2013-June/009320.html" target="_blank">http://lists.openvz.org/pipermail/criu/2013-June/009320.html</a> but it<br>
> > > didn't help.<br>
> > > The usage scenario is following: I'm having a parent process and a child processes communicating<br>
> > > via stream Unix socket. The idea is to dump child process when it's not needed and to restore it<br>
> > > again later,<br>
> ><br>
> > But what to do with this connection upon restore?<br>
> ><br>
> > Sorry, but I'm afraid, I didn't understand you question. I intended to continue sending streamed data<br>
> > from the point where it was dumped. Did you mean I won't be able to use the connection after I restore it?<br>
><br>
> Well, child will be able to do it, but what about parent? Once you dumped the child<br>
> and killed one parent would notice the EOF on the socket and will close it. So after<br>
> restore of child there will be no "peer" to send data to.<br>
><br>
><br>
> Hi again,<br>
><br>
> I can see few hypothetical possibilities here:<br>
> 1) I can try to keep the socket in parent process alive if possible. For example, I can try to not to send EOF from the child process.<br>
<br>
You can't force child not to send EOF :) Kernel will do it for you once child is<br>
dumped AND killed afterwards.<br>
<br>
> 2) I can try to embed criu in parent process and build logic around it, for example re-open parent socket when restoring child.<br>
<br>
Well, if you control the parent, then this situation can be resolved.<br>
What you're<br>
trying to achieve seems to be the case for FD inheritance on restore<br>
[1]. We have<br>
it implemented for pipes and regular files only, so we'll need to<br>
extend that logic<br>
on unix sockets as well :)<br>
<br>
[1] <a href="http://criu.org/Inheriting_FDs_on_restore" target="_blank">http://criu.org/Inheriting_FDs_on_restore</a><br>
<br>
-- Pavel<br>
_______________________________________________<br>
CRIU mailing list<br>
<a href="mailto:CRIU@openvz.org" target="_blank">CRIU@openvz.org</a><br>
<a href="https://lists.openvz.org/mailman/listinfo/criu" target="_blank">https://lists.openvz.org/mailman/listinfo/criu</a><br>
</blockquote></div><br><br>Hi all,</div><div class="gmail_extra"><br></div><div class="gmail_extra">We're returned back at this problem..</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">> > > The usage scenario is following: I'm having a parent process and a child processes bidirectonal communicating<br>> > > via stream Unix socket. The idea is to dump child process when it's not needed and to restore it<br>> > > again later</div></div><div class="gmail_extra"><br></div><div class="gmail_extra">This task still need for us and we did some test with upstream version of <span style="background:yellow">CRIU</span>.</div><div class="gmail_extra">Code of test stub here -> http://<span style="background:yellow">pastebin</span>.com/tLnRdE3K</div><div class="gmail_extra"><span style="background:yellow">CRIU</span> called with next <span style="background:yellow">params</span>:</div><div class="gmail_extra">for dump -> ${<span style="background:yellow">CRIU</span>_bin} dump -<span style="background:yellow">vvvv</span> -o <<span style="background:yellow">PID</span>>.log -D ${DIR} -t <<span style="background:yellow">PID</span>> -d --shell-job --ext-<span style="background:yellow">unix</span>-<span style="background:yellow">sk</span></div><div class="gmail_extra">for restore -> ${<span style="background:yellow">CRIU</span>_bin} restore -<span style="background:yellow">vvvv</span> -o <<span style="background:yellow">PID</span>>.log -D ${DIR} -d --shell-job --ext-<span style="background:yellow">unix</span>-<span style="background:yellow">sk</span></div><div class="gmail_extra"><br></div><div class="gmail_extra">Test case: child write in a unix sock, parent read from unix sock.</div><div class="gmail_extra"><div class="gmail_extra">Child proccess dumped&restored, but</div><div class="gmail_extra"> - only if we don't close sockets after fork (sock[0] in child and sock[1] in parent respectively) otherwise restore process failed</div><div class="gmail_extra"> - child PPID not equal parent pid </div><div class="gmail_extra"> - connection lost</div></div><div class="gmail_extra"><br></div><div class="gmail_extra">P.S. Also we are checked pipes (instead of <span style="background:yellow">socketpair</span>)</div><div class="gmail_extra">Test case 1: child write in a pipe, parent read from pipe. </div><div class="gmail_extra">Child <span style="background:yellow">proccess</span> dumped&restored, but</div><div class="gmail_extra"> - child <span style="background:yellow">PPID</span> not equal parent <span style="background:yellow">pid</span> </div><div class="gmail_extra"> - connection lost with another end of pipe(continue sending messages into pipe)<br></div><div class="gmail_extra">Test case 2: child read in a pipe, parent write from pipe. <br></div><div class="gmail_extra">As expected parent received SIGPIPE.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><span style="background:yellow">Sumary</span> questions:</div><div class="gmail_extra">1. Can we restored relation (subtree) between parent and child process?</div><div class="gmail_extra">2. Do you have a plan for <span style="background:yellow">imp of</span> dump\restore functionality for unix sockets with option SOCK_SEQPACKET and SOCK_STREAM (created by socketpair call) in near time?</div><div class="gmail_extra">3. Do you have any ideas which can help us make a dump\restore of child proccess with CRIU?</div><div class="gmail_extra"><br></div><div class="gmail_extra">-- <br><div><div dir="ltr">Best regards,<div><span style="background:yellow">Artem</span> <span style="background:yellow">Kuzmitskiy</span></div><div><span style="background:yellow">Severnoe</span> DB <span style="background:yellow">JSC</span></div></div></div>
</div></div>