[CRIU] pstree C/R problems

[Pavel Emelyanov]

On 09/27/2012 04:37 PM, Huang Qiang wrote:
> On 2012/9/27 20:19, Pavel Emelyanov wrote:
>>>> The problem here is not technical one, ie we can simply allow to continue
>>>> execution but imagine your program remembered somewhere in local variables
>>>> own sid and uses it for some needs, and now it's restored with inherited sid
>>>> which no longer match the value before. Should we continue? To be fair, I
>>>> don't know. I guess sich behaviour should be allowed IIF some command line
>>>> option passed to crtools, ie when a user knows what he is doing and forces
>>>> crtools to continue even with sid changed.
>>>>
>>>
>>> Yes, changing sid is the least thing we want to see. But I think we can still
>>> keep the sid as we dumped even if we don't have a session leader root.
>>> Like I said, a helper for the root may solve this, or maybe other ways, what
>>> made you think the sid will be changed if we allow this? what do I miss?
>>
>> On restore time the sid you want to put on your task can be already busy with
>> some other task.
>>
> 
> Yes, I thought about this, maybe we should just fail in this case. Don't we have
> the same issue if the process id is already busy?(without pid namespace)
> 
>> A good scenario can be -- if crtools were launched with --detach option we can
>> indeed create an intermediate helper that will be the desired sid leader (and
>> then die, thus doing both -- session restore and detach). Is that OK for you?
>>
> 
> That's exactly what I thought! Maybe we should do this even without --detach
> option. The helper should not exist after restore anyway.

We can't do it w/o top-level helper. And if it exits --detach will happen automatically.
Thus I think we'd better combine these options.

>>>> .
>>>>
>>>
>>>
>>> _______________________________________________
>>> CRIU mailing list
>>> CRIU at openvz.org
>>> https://openvz.org/mailman/listinfo/criu
>>> .
>>>
>>
>>
>>
> 
> 
> .
>