[CRIU] criu + threaded program + TCP_REPAIR

[Pavel Emelyanov]

On 10/20/2014 05:51 PM, Sowmini Varadhan wrote:
> On (10/20/14 16:07), Pavel Emelyanov wrote:
>> The criu binary should be in PATH.
> 
> yes, my bad. I fixed that after Ruslan pointed it out.
> 
>> If you're specifying the lxc as the 2nd argument, then 3rd should be
>> the container name as lxc understands it.
> 
> Ok. 
> 
>> 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.
> 
> yes ns_child_exec calls clone with CLONE_NEWPID, so the child (in
> my case, this is bash) is in its own pidns. My understanding is that
> you need to do this so that you can migrate the process over without
> any pid conflicts. But I guess I'm not clear on what needs to
> be migrated at that point (bash? or its child? or the parent of bash?)
> 
> My top-level objective is to migrate the child of bash, which is
> iperf in my case.
> 
>> 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.
>   :
>> Can you show what /proc/pid/maps shows for the iperf process?
> 
> I assume you want the cat from the default pidns (cat from the 
> child's pidns doesnt show anything). The output was a  bunch of stuff, see 
> attachment
> 
> But as I wrote this up, started wondering,
> perhaps all I want is to do the criu-restore in a separate pidns?

CRIU found a mapping at f7786000 start address. In your output there's
no such mapping. Can you post the full dump.log collected with v4 please?

>