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

From: Karl Pickett
Date: Fri Mar 30 2012 - 09:26:47 EST



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.
>>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/