Messages in this thread | | | Subject | Re: Is prctl(PR_SET_CHILD_SUBREAPER) going to break my code which checks getppid == 1? | From | Karl Pickett <> | Date | Fri, 30 Mar 2012 08:26:44 -0500 |
| |
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. >> >
| |