[CRIU] Dumping tmux session with a client connected
Allan Cecil
ac at sonic.net
Mon Apr 13 09:43:55 PDT 2015
On 04/13/2015 02:41 AM, Pavel Emelyanov wrote:
> 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
>
Here is a newly created environment:
15349 ? Ss 0:00 criu service -d
15957 ? Ss 0:00 tmux
15958 pts/3 Ss 0:00 \_ -bash
15972 pts/3 S+ 0:00 \_ top
ac at lbox:~$ ss -xup
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
u_str ESTAB 0 0 * 53357 * 53358
u_str ESTAB 0 0 * 43478 * 43479
u_str ESTAB 0 0 * 43472 * 43473
u_str ESTAB 0 0 * 52373 * 52372 users:(("tmux",15957,4))
u_str ESTAB 0 0 * 9725 * 9746
u_str ESTAB 0 0 * 52368 * 52367 users:(("tmux",15957,7))
u_str ESTAB 0 0 * 53545 * 53544
u_str ESTAB 0 0 @/com/ubuntu/upstart 8780 * 8746
u_str ESTAB 0 0 * 9359 * 9358
u_str ESTAB 0 0 * 52367 * 52368 users:(("tmux",15955,6))
u_str ESTAB 0 0 @/com/ubuntu/upstart 8678 * 8673
u_str ESTAB 0 0 /var/run/dbus/system_bus_socket 53362 * 53361
u_str ESTAB 0 0 * 52372 * 52373 users:(("tmux",15957,3))
u_str ESTAB 0 0 * 43473 * 43472
u_str ESTAB 0 0 * 53358 * 53357
u_str ESTAB 0 0 * 53548 * 53549
u_str ESTAB 0 0 /var/run/dbus/system_bus_socket 53549 * 53548
u_str ESTAB 0 0 /var/run/dbus/system_bus_socket 43479 * 43478
u_str ESTAB 0 0 * 8673 * 8678
u_str ESTAB 0 0 @/com/ubuntu/upstart 9746 * 9725
u_str ESTAB 0 0 * 52365 * 52364 users:(("tmux",15955,4))
u_str ESTAB 0 0 * 53361 * 53362
u_str ESTAB 0 0 * 53544 * 53545
u_str ESTAB 0 0 * 52364 * 52365 users:(("tmux",15955,3))
u_str ESTAB 0 0 * 9358 * 9359
u_str ESTAB 0 0 * 8746 * 8780
u_str ESTAB 0 0 * 9366 * 9367
u_str ESTAB 0 0 * 8835 * 8836
u_str ESTAB 0 0 /var/run/dbus/system_bus_socket 9367 * 9366
u_str ESTAB 0 0 /var/run/dbus/system_bus_socket 8836 * 8835
Just in case it helps I've attached a failed dump for process 15957.
I will attempt to create an asciinema showing how the system works now (using KVM snapshots) so you can get a feel for what the end state will look like if I can get this working. At the moment, I will likely need to proceed forward with creating an "outer" tmux session and an "inner" tmux session, having the outer session detach from the inner prior to doing the dump and reattaching after every restore, but it will cause screen flashing. I'll see how far I can get with that method, though.
Thanks again for the interest and support,
A.C.
******
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 15957.tar.gz
Type: application/gzip
Size: 421884 bytes
Desc: not available
URL: <http://lists.openvz.org/pipermail/criu/attachments/20150413/0e38b30a/attachment-0001.bin>
More information about the CRIU
mailing list