[CRIU] Bad commit

[Pavel Emelyanov]

On 08/14/2014 04:18 PM, Cyrill Gorcunov wrote:
> On Thu, Aug 14, 2014 at 04:16:04PM +0400, Cyrill Gorcunov wrote:
>> Guys, commit
>>
>> [root at pcs criu]# git bisect good
>> e301b1d56c5c56155c68fa2f6ef4f5a716d0217b is the first bad commit
>> commit e301b1d56c5c56155c68fa2f6ef4f5a716d0217b
>> Author: Tycho Andersen <tycho.andersen at canonical.com>
>> Date:   Wed Aug 13 21:23:00 2014 +0400
>>
>>     restore: --restore-detached implies CLONE_PARENT
>>     
>>     We need to use CLONE_PARENT to prevent processes from immediately dying due to
>>     pdeath_sig when they are restored in detached mode.
>>     
>>     [ xemul: One more place which requires check for restore-detach
>>              is in sigactions preparation ]
>>     
>>     Signed-off-by: Tycho Andersen <tycho.andersen at canonical.com>
>>     Signed-off-by: Pavel Emelyanov <xemul at parallels.com>
>>
>> ruined my restore process for the container :(

For what container?

>> (00.039241) Error (cr-restore.c:1006): Can't fork for 1: Invalid argument
> 
> It's because of
> 
> copy_process
> 	...
> 	/*
> 	 * Siblings of global init remain as zombies on exit since they are
> 	 * not reaped by their parent (swapper). To solve this and to avoid
> 	 * multi-rooted process trees, prevent global and container-inits
> 	 * from creating siblings.
> 	 */
> 	if ((clone_flags & CLONE_PARENT) &&
> 				current->signal->flags & SIGNAL_UNKILLABLE)

UNKILLABLE??? The caller of criu is unkillable?! Why?

> 		return ERR_PTR(-EINVAL);
> 
> I think the commit should be reverted.

The same should be true for criu_restore_sub() as it uses the same
technique. Let's investigate the issue.

Thanks,
Pavel