Is prctl(PR_SET_CHILD_SUBREAPER) going to break my code which checks getppid == 1?

Is prctl(PR_SET_CHILD_SUBREAPER) going to break my code which checks getppid == 1?

[Karl Pickett]

Re: http://thread.gmane.org/gmane.linux.kernel/1236479

I'm wondering if this is going to break code that checks getppid() == 1?

I have a TCL/TK GUI app that spawns ssh.  I want the ssh to die immediately if the GUI process crashes, so ssh is launched with a wrapper c program that does:

   prctl(PR_SET_PDEATHSIG, SIGHUP);
   if (getppid() == 1) /* parent died already? */
       return 0;

So what is getppid() going to return for some user using this new 'session manager reaper'?  How else am I supposed to do proper processes supervision (with TCL/TK as a parent...)?  Also, this program is open source but we distribute binaries that work on as many platforms as possible... we find most users don't want to compile things.

Re: Is prctl(PR_SET_CHILD_SUBREAPER) going to break my code which checks getppid == 1?

[Oleg Nesterov]

On 03/29, Karl Pickett wrote:
>
> Re: http://thread.gmane.org/gmane.linux.kernel/1236479
>
> I'm wondering if this is going to break code that checks getppid() == 1?
>
> I have a TCL/TK GUI app that spawns ssh.  I want the ssh to die
> immediately if the GUI process crashes, so ssh is launched with a wrapper
> c program that does:
>
>    prctl(PR_SET_PDEATHSIG, SIGHUP);
>    if (getppid() == 1) /* parent died already? */
>        return 0;

Yes, this won't work if the parent of this app does PR_SET_CHILD_SUBREAPER.

> So what is getppid() going to return for some user using this new
> 'session manager reaper'?

The new parent's pid ;)

Perhaps you can do something like

	ppid_for_child = getpid();

	if (!fork()) {
		// Child
		prctl(PR_SET_PDEATHSIG);
		if (getppid() != ppid_for_child)
			return;
		...
	}

Just in case, I do not know how PR_SET_CHILD_SUBREAPER will be really used.
I do not know if systemd will run the "normal" user applications under
PR_SET_CHILD_SUBREAPER. Probably yes, but this is the question to Kay.

Oleg.

Re: Is prctl(PR_SET_CHILD_SUBREAPER) going to break my code which checks getppid == 1?

[Karl Pickett]

On Mar 30, 2012, at 7:44 AM, Oleg Nesterov wrote:

> On 03/29, Karl Pickett wrote:
>> 
>> Re: http://thread.gmane.org/gmane.linux.kernel/1236479
>> 
>> I'm wondering if this is going to break code that checks getppid() == 1?
>> 
>> I have a TCL/TK GUI app that spawns ssh.  I want the ssh to die
>> immediately if the GUI process crashes, so ssh is launched with a wrapper
>> c program that does:
>> 
>>   prctl(PR_SET_PDEATHSIG, SIGHUP);
>>   if (getppid() == 1) /* parent died already? */
>>       return 0;
> 
> Yes, this won't work if the parent of this app does PR_SET_CHILD_SUBREAPER.
> 
>> So what is getppid() going to return for some user using this new
>> 'session manager reaper'?
> 
> The new parent's pid ;)
> 
> Perhaps you can do something like
> 
> 	ppid_for_child = getpid();
> 
> 	if (!fork()) {
> 		// Child
> 		prctl(PR_SET_PDEATHSIG);
> 		if (getppid() != ppid_for_child)
> 			return;
> 		...
> 	}

There are two problems with that.  1., I don't think TCL/TK lets me access the parent pre-fork env like that - all I can change is the execed code.  2., That has a clear race with pid wrap around.  You really need a prctl(PR_DID_MY_REAL_PARENT_DIE) function to be safe.


> 
> Just in case, I do not know how PR_SET_CHILD_SUBREAPER will be really used.
> I do not know if systemd will run the "normal" user applications under
> PR_SET_CHILD_SUBREAPER. Probably yes, but this is the question to Kay.
> 
> Oleg.
> 

Re: Is prctl(PR_SET_CHILD_SUBREAPER) going to break my code which checks getppid == 1?

[Karl Pickett]

On Mar 30, 2012, at 8:17 AM, Karl Pickett wrote:

> On Mar 30, 2012, at 7:44 AM, Oleg Nesterov wrote:
> 
>> On 03/29, Karl Pickett wrote:
>>> 
>>> Re: http://thread.gmane.org/gmane.linux.kernel/1236479
>>> 
>>> I'm wondering if this is going to break code that checks getppid() == 1?
>>> 
>>> I have a TCL/TK GUI app that spawns ssh.  I want the ssh to die
>>> immediately if the GUI process crashes, so ssh is launched with a wrapper
>>> c program that does:
>>> 
>>>  prctl(PR_SET_PDEATHSIG, SIGHUP);
>>>  if (getppid() == 1) /* parent died already? */
>>>      return 0;
>> 
>> Yes, this won't work if the parent of this app does PR_SET_CHILD_SUBREAPER.
>> 
>>> So what is getppid() going to return for some user using this new
>>> 'session manager reaper'?
>> 
>> The new parent's pid ;)
>> 
>> Perhaps you can do something like
>> 
>> 	ppid_for_child = getpid();
>> 
>> 	if (!fork()) {
>> 		// Child
>> 		prctl(PR_SET_PDEATHSIG);
>> 		if (getppid() != ppid_for_child)
>> 			return;
>> 		...
>> 	}
> 
> There are two problems with that.  1., I don't think TCL/TK lets me access the parent pre-fork env like that - all I can change is the execed code.  2., That has a clear race with pid wrap around.  You really need a prctl(PR_DID_MY_REAL_PARENT_DIE) function to be safe.

Maybe there is not a race with pid wrap around since that can not create a 'new' parent for me?  Too early in the morning.  

1 init -> 2 Subreaper -> 3 Gui App -> 4 ssh.  If 3 (gui app dies), is there any way another process with pid 3 could become my parent?   

Maybe with TCL/TK I could set an environment variable that records its pid.  I already thought about this, but for some reason was still thinking pid wrap around would happen.  However, that requires access to that programs source code (which I fortunately have) but I think the authors of the patch need to recognize the compatibility problems of this patch and provide a better workaround (like PR_DID_MY_REAL_PARENT_DIE).  Otherwise, PR_SET_PDEATHSIG is not as useful as it has been for quite some time.

> 
> 
>> 
>> Just in case, I do not know how PR_SET_CHILD_SUBREAPER will be really used.
>> I do not know if systemd will run the "normal" user applications under
>> PR_SET_CHILD_SUBREAPER. Probably yes, but this is the question to Kay.
>> 
>> Oleg.
>> 
> 

Re: Is prctl(PR_SET_CHILD_SUBREAPER) going to break my code which checks getppid == 1?

[Oleg Nesterov]

On 03/30, Karl Pickett wrote:
>
> On Mar 30, 2012, at 7:44 AM, Oleg Nesterov wrote:
>
> > Perhaps you can do something like
> >
> > 	ppid_for_child = getpid();
> >
> > 	if (!fork()) {
> > 		// Child
> > 		prctl(PR_SET_PDEATHSIG);
> > 		if (getppid() != ppid_for_child)
> > 			return;
> > 		...
> > 	}
>
> There are two problems with that.  1., I don't think TCL/TK lets me access
> the parent pre-fork env like that - all I can change is the execed code.

Can't comment this, I do not know tcl/tk

> 2., That has a clear race with pid wrap around.

Not really. This ppid_for_child can be re-used, yes. But the new process
which gets this pid can't become the parent, getppid() can't return this
number.

Btw, PR_SET_PDEATHSIG + getppid() check is racy anyway (with or without
PR_SET_CHILD_SUBREAPER), it can race with reparenting. But the window is
tiny and the problem is purely theoretical I think.

> You really need a
> prctl(PR_DID_MY_REAL_PARENT_DIE) function to be safe.

Oh, I don't know. Sure, PR_SET_CHILD_SUBREAPER can confuse the child.
Just suppose it does daemonize() + assert(getppid() == 1). But this
is not the kernel problem.

Oleg.