No subject

now we have the following options.

1) CLI
	a) Usually
	task calling criu
	 `- criu
	     `- root restored task

	b) when --restore-detached AND root has pdeath_sig

	task calling criu
	 `- criu
	 `- root restored task

2) Library/SWRK

	task using lib/swrk
	 `- criu
	 `- root restored task

3) Standalone service

	a) Usually
	service
	 `- service sub task
	     `- root restored task

	b) when root has pdeath_sig
	criu service
	 `- criu sub task
	 `- root restored task

It looks quite messy, I'd prefer that criu restore always create
root task as sibling, but we have three constraints:

First, the case 1.a is kept for two reasons. First, 3.11 doesn't allow
CLONE_PARENT | CLONE_NEWOPID, but zdtm wants to run tests in pid ns.

Second, CLI w/o --restore-detach waits for the restored task to die and
this behavior can be "expected" already.

Third, in case of standalone service tasks shouldn't become service's
children.

And I have one "plan". The p.haul project while live migrating tasks
on destination node starts a service, which uses library/swrk mode. In
this case the restored processes become p.haul service's kids which is
also not great.

How about adding the 2nd option called --restore-child and make their
meaning look like this:


* detached AND child:

task
 `- criu restore (exits at the end)
 `- root task

The root task will become task's child.
This will be default to library/swrk.
This is what you need.


* detach AND !child

task
 `- criu restore (exits at the end)
     `- root task

The root task will get re-parented to init.
This will be compatible with 1.3.
This will be default to standalone service and
to my wish with the p.haul case.


* !detach AND child

task
 `- criu restore (waits for root task to die)
 `- root task

This should be deprecated, I suppose, so that criu restore
doesn't mess with task <-> root task signalling.


* !detach AND !child

task
 `- criu restore (waits for root task to die)
     `- root task

This is how plain criu restore works now.

> In LXC we depend (well, it won't break anything except for convention)
> on this behavior, so it would be nice to keep it consistent.
> 
>> BTW, the --restore-detach is the CLI use-case. We also have the
>> scenario when we restore tasks from standalone service, in that
>> case restore tasks must get re-parented to init and thus must
>> be born as criu child. And we have the criu_restore_child() case
>> -- here the task must be born as criu sibling. %)
> 
> Yes, although I think all three usecases are solved by dropping the
> last part of the &&, except that zdtm won't let us :(
> 
>>> Another problem is that we don't actually have the core when we are
>>> setting up the signals, those are loaded in fork_with_pid.
>>
>> Damn :( And thus we don't have any ideas whether or not we're should
>> use the root_as_sibling. It's already midnight in MSK, so I need some
>> time-out to think what we can do about it, sorry. But if you have some 
>> good idea -- don't wait for me to wake up :)
> 
> I think we can just unmask SA_NOCLDSTOP when we PTRACE_SEIZE. I will
> send a patch.
> 
> Tycho
> .
>