[CRIU] Dumping tmux session with a client connected

Pavel Emelyanov xemul at parallels.com
Mon Apr 13 02:41:27 PDT 2015


On 04/13/2015 09:24 AM, Allan Cecil wrote:
> Greetings,
> 
> (resend, sorry if this is a duplicate)
> 
> I am continuing my quest to develop a general-purpose "wrapper" where you can run a Python script which
> starts a shell and you can run a program such as top and hit a key combination such as Ctrl+U to save a
> checkpoint and then press Ctrl+O later to restore that checkpoint, all while viewing the shell.

Wow! Let us know when it will be finished, it's very cool use case.

> Using top is a quick example but the ultimate goal is to get this working with NetHack as part of the 
> nethack-tas-tools project (currently on Gitorious but soon to move to a new repository).
> 
> I'm having issues dumping when a client is connected to the tmux session. Given ps fax:
> 
> 15349 ?        Ss     0:00 criu service -d
> 15323 ?        Ss     0:00 tmux
> 15324 pts/2    Ss     0:00  \_ -bash
> 15619 pts/2    S+     0:00      \_ top
> 
> Using "./criuDump.py 15323" (script attached) fails; the full dump folder is attached - the pertinent bit is:
> 
> (00.019450)     Ext stream not supported: ino 0xbfc1 peer_ino 0xc1fb family    1 type    1 state  1 name (null)
> (00.019453) Error (sk-unix.c:564): Can't dump half of stream unix connection.

Can you check with "ss -xup" command what this socket is and which two processes are connected?

> I'm using req.opts.ext_unix_sk = True because without it I get warnings that it's required.  So, my question
> is, is it possible to use RPC to dump tmux if a client is currently connected?  (I can reliably dump tmux when
> "no one is watching" which reminds me of Wheatley from Portal 2, but I digress...   I am not tied to using tmux
> for this, but it seems like the most sensible option that would provide the most flexibility.
> 
> Any suggestions would be appreciated.  Thanks!

The problem with "external" unix connections is that once you dumped one end and killed the
processes that other end notices the EOF and most typically closes it. So on restore you have
nothing to connect to. In general case there's no way to solve this as we have to somehow
"explain" to the other end that the former connection is coming back. For each particular case
there can exist a solution. Let's try to find out what the tmux socket is. :)

-- Pavel


More information about the CRIU mailing list