<div dir="ltr">Thanks, this is all very interesting. How does the story change for tcp sockets?</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 21, 2015 at 5:03 AM, Pavel Emelyanov <span dir="ltr"><<a href="mailto:xemul@parallels.com" target="_blank">xemul@parallels.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 04/19/2015 04:48 AM, Ross Boucher wrote:<br>
> Hey everyone,<br>
<br>
Hi, Ross.<br>
<span class=""><br>
> I've been trying to figure out both what happens when you checkpoint an open socket<br>
> and what my options are for restoring that socket (or maybe doing something else at<br>
> that point in time). It might be best to just describe the program I have and what<br>
> I want to accomplish.<br>
><br>
> I have two programs communicating over a socket. Program A opens a socket and listens<br>
> for connections, and then program B connects to it. They essentially exchange messages<br>
> forever in a pattern something like:<br>
><br>
> A -> B send next message<br>
> B -> A ok, here's the next message<br>
><br>
> Obviously, in between, A performs some actions. The goal is to checkpoint A after each<br>
> message is processed and before the next is received (while leaving the process<br>
> running), so that we can restore to any previous state and reprocess possibly changed<br>
> messages.<br>
<br>
</span>First thing that comes to mind is that --track-mem thing definitely makes sense for<br>
such frequent C/R-s. But that's a side note :)<br>
<span class=""><br>
> It's completely fine for our use case to have to re-establish that socket connection,<br>
> we don't actually need or want to try and magically use the same socket (since program<br>
> B has probably moved on to other things in between).<br>
<br>
</span>Hm.. OK.<br>
<span class=""><br>
> Is this a use case for a criu plugin?<br>
<br>
</span>Well, I would say it is, but there are two things about it. First is that we don't have any<br>
hooks in CRIU code for sockets, so patching will be required. And the second is -- many<br>
people are asking for handling the connected unix socket, so I think we'd better patch<br>
criu itself to provide some sane API rather than make everybody invent their own plugins :)<br>
<br>
So, I see two options for such an API.<br>
<br>
The first is to extend the --ext-unix-sk to accept socket ID as an argument that would<br>
force even stream sockets to be marked as "external" and not block the dump. On restore<br>
the --ext-unix-sk with $ID would make CRIU connect the restored unix socket back to its<br>
original path. Optionally we can make the argument look like $ID:$PATH and connect to<br>
$PATH instead.<br>
<br>
The other option would be to still teach dump accept the --ext-unix-sk $ID parameter. On<br>
restore you can create the connection yourself and then pass it into CRIU with --inherit-fd<br>
argument. We already have fd inheritance for pipes and files [1], but we can patch CRIU<br>
to support it for sockets too.<br>
<br>
[1] <a href="http://criu.org/Inheriting_FDs_on_restore" target="_blank">http://criu.org/Inheriting_FDs_on_restore</a><br>
<span class=""><br>
> I've tried playing around with the ext-unix-sk flag but I haven't quite figured anything<br>
> out yet.<br>
<br>
</span>The --ext-unix-sk is for datagram sockets as they are stateless and we can just close and<br>
re-open one back w/o any risk that the peer notices it.<br>
<div class="HOEnZb"><div class="h5"><br>
> Any help would be appreciated. Thanks!<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">-- Pavel<br>
</font></span></blockquote></div><br></div>