[CRIU] pstree C/R problems

[Huang Qiang]

On 2012/9/27 20:21, Cyrill Gorcunov wrote:
> On Thu, Sep 27, 2012 at 08:05:05PM +0800, Huang Qiang 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?
> 
> It seems I've missed something from your mails. Look, you're dumping a subtree,
> right? Then you restore it and crtools finds that inherited sid is not longer
> the same as being on dump, and finally it aborts to continue. Correct? So
> if we're not session leaders on dump we should not try to become it on
> restore I think. Or you mean something else?
> 

It seem you still not get the point. I think Pavel already get it :)
I think we can find a solution for that subtree C/R error, but not make the
non session leader be a session leader after restore, nor change any sid.

Whatever solution it will be, the current logic you said above should be changed,
because they are the direct reason why my test case failed.

>