[CRIU] Anyone have a plan to support dumping of stream unix connection?

James Bottomley jbottomley at parallels.com
Fri Jun 14 17:33:24 EDT 2013


On Wed, 2013-06-12 at 18:31 +0400, Pavel Emelyanov wrote:
> On 06/12/2013 03:33 AM, Brandon Philips wrote:
> > On Tue, Jun 11, 2013 at 9:23 AM, Pavel Emelyanov <xemul at parallels.com> wrote:
> >> Presumably it's not going to be real repair :) I suppose that for scenarios
> >> you describe simple disconnect on dump + connect back on restore would work.
> >> Am I right?
> > 
> > In the case of the systemd-journal the code seems to send a header
> > before hooking up stdout. So, you would have to open, write the header
> > then restart, right? Is that what you mean by repair?
> 
> Yes, something like that, but we need to know the detail of this "handshake"
> to replay them. Other than this, imagine we have two types of handshakes,
> one for systemd-journal and the other one for some other server. Thus we'd
> have to guess in criu which type of connection it is to use the proper
> handshake.

Actually, the solution isn't for us to know the details of the
handshake, because that's fragile and would likely break with every
update to systemtap, it's for systemtap to make the protocol
restartable, like NFS.  So if we checkpoint the process with the socket
data and restart on a new node connecting to a new systemtap instance,
the log happens even if systemtap on the new node sees the first few
packets as corrupt and asks for a replay.

James




More information about the CRIU mailing list