[CRIU] criu + threaded program + TCP_REPAIR

[Pavel Emelyanov]

On 10/20/2014 05:39 AM, Sowmini Varadhan wrote:
> On (10/19/14 20:03), Ruslan Kuprieiev wrote:
>>>    python-protobuf[.socketrpc]
>>
>> You don't need python-protobuf.socketrpc. rpc_pb2.py and stats_pb2.py
>> are to be generated by running "make" in p.haul root directory.
>> Just sent the patch to explain how to get p.haul ready.
> 
> Thanks!
> 
> One more piece of useful info for the HOWTO page - in 
> addition to the protobuf packages listed in the criu page,
> and python-protobuf, you also need protobuf-compiler (for protoc).
> 
> But even after all that, I run into this:
> root at vm:~/src/p.haul# ./p.haul lxc 31692 192.168.122.54
> Connecting to target host
> Setting up local
> `- Passing (ctl:5, data:4) pair to CRIU
> Traceback (most recent call last):
>   File "./p.haul", line 37, in <module>
>     worker = ph_iters.phaul_iter_worker(ph_type, dst)
>   File "/home/sowmini/src/p.haul/p_haul_iters.py", line 35, in __init__
>     self.criu = criu_api.criu_conn(self.data_sk)
>   File "/home/sowmini/src/p.haul/criu_api.py", line 40, in __init__
>     self._swrk = subprocess.Popen([criu_binary, "swrk", "%d" % css[0].fileno()])
>   File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
>     errread, errwrite)
>   File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
>     raise child_exception
> OSError: [Errno 2] No such file or directory

The criu binary should be in PATH.

> 
> Here the 31692 is pid of the init for the lxc, and the IP address
> is the address of the target VM.  Looks like we did connect to the
> target, but something went wrong when talking to the local criu service,
> The log file for the criu service doesnt show anything remarkable
> root at vm:~/src/criu# cat /tmp/criu.log
>   (00.000515) The service socket is bound to /var/run/criu_service.socket
>   (00.000986) Waiting for connection...
> So am I missing something obvious here (before I try to debug this further)?

If you're specifying the lxc as the 2nd argument, then 3rd should be
the container name as lxc understands it.

> and, back to the "do this from First Principles" question..  If I do  this;
> 
>>> In any case, I also tried to just spawn my process from something like
>>> ns_child_exec.c [http://lwn.net/Articles/533492/].
>>>
>>> So if I do this:
>>>
>>>   # ns_child_exec -v -p bash
>>>   pidns# iperf -s &
> And try to do a dump using the pid of ns_child_exec, I get:
> 
>>> Error (namespaces.c:196): Can't dump nested pid namespace for 15022
>>> Error (namespaces.c:392): Can't make pidns id

I don't know what ns_chil_exec does, but it's likely generating
a new pid namespace for its child. Criu doesn't support more than
one pidns at the moment.

> If I do this with the pid of bash, I get an error about 
> 
>>> Error (cr-dump.c:1581): A session leader of 27223(1) is outside of its pid namespace
>>> Error (cr-dump.c:1949): Dumping FAILED.

Yes. This means, that bash lives not in its own session, but the
session leader is somewhere else. If you do want to dump this guy
and (!) on restore re-attach it to another session, then the -j key
is for you.

> If I do this with the pid of iperf, I get 
> 
>>> Error (proc_parse.c:357): Unsupported mapping found 00000000f7786000-00000000f7788000
>>> Error (bfd.c:118): Error flushing image

Can you show what /proc/pid/maps shows for the iperf process?

> Which pid should I use, if I want to directly use criu itself?
> 
> --Sowmini
> 
> .
>