[CRIU] pstree C/R problems

[Huang Qiang]

On 2012/9/27 19:48, Cyrill Gorcunov wrote:
> On Thu, Sep 27, 2012 at 07:36:16PM +0800, Huang Qiang wrote:
>> On 2012/9/27 16:41, Cyrill Gorcunov wrote:
>>> On Thu, Sep 27, 2012 at 03:59:49PM +0800, Huang Qiang wrote:
>>>> HI:
>>>> I use a simple code to test CRIU, when it runs, the ids seem like this:
>>>>
>>>> UID        PID  PPID  PGID   SID  C STIME TTY          TIME   CMD
>>>> root     11988  9904 11988 11988  0 10:37 ?        00:00:00     sshd: root at pts/3
>>>> root     11996 11988 11996 11996  0 10:37 pts/3    00:00:00       -bash
>>>> root     12056 11996 12056 11996  0 10:38 pts/3    00:00:00         ./multitask_simple
>>>> root     12057 12056 12056 11996  0 10:38 pts/3    00:00:00           ./multitask_simple
>>>>
>>>> then I run:
>>>> # ./crtools dump -D /home/hq/image -t 12056
>>>> it is successful.
>>>>
>>>> then restore it:
>>>> # ./crtools restore -D /home/hq/image -t 12056
>>>> I got error:
>>>>  12057: Error (cr-restore.c:677): Requested sid 11996 doesn't match inherited 11952
>>>>  12056: Error (cr-restore.c:633): 12057 exited, status=1
>>>> Error (cr-restore.c:911): Someone can't be restored
>>>>
>>>> I read the pstree C/R code, and found that it didn't handle the situation that
>>>> the root task is not the session leader. But if there is only one task in the tree,
>>>> C/R can successful, otherwise, will face the error.
>>>
>>> As far as I know it's expected behaviour when subtree is dumped
>>> (see commit 1264a7a9c6d42d3bdf383082c141c08ccf5744ac).
>>>
>>
>> I see, thanks.
>>
>>>> Is this a bug? Or is CRIU has a limitation right now for the root task?
>>>> And what's your plan for this situation?
>>>> I think we may also need a helper for root task, of course have other things to consider.
>>>
>>> I can't tell for all team but as for me -- when subtree is dumped there
>>> are a number of limitation applies and this is not a scenario which is
>>> encouraged. So I would say we prefer when the complete tree is dumped,
>>> still subtree dumping is allowed but with a number of limitations.
>>>
>>
>> I agree with you that we should encourage to dump a complete tree. But as you said,
>> subtree dumping is still allowed, so the problem is depend on what's the limitations.
>>
>> I think some missing is acceptable for subtree dumping, something like, before dump,
>> process are in foreground process group, but they will be in background process group
>> after restore.
>>
>> Whatever the missing is, that simple and common test case like I used should not return
>> error, right?
>> What do you think Cyrill?
> 
> 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?

> .
>