[CRIU] pstree C/R problems

[Huang Qiang]

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.

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