linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lennart Poettering <mzxreary@0pointer.de>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] exit: PR_SET_ANCHOR for marking processes as reapers for child processes
Date: Wed, 3 Feb 2010 10:53:41 +0100	[thread overview]
Message-ID: <20100203095339.GA10050@tango.0pointer.de> (raw)
In-Reply-To: <20100203172006.D3B2.A69D9226@jp.fujitsu.com>

On Wed, 03.02.10 17:24, KOSAKI Motohiro (kosaki.motohiro@jp.fujitsu.com) wrote:

> 
> > [ I already sent this patch half a year ago or so, as an RFC. I didn't
> > really get any comments back then, however I am still interested in
> > seeing this patch in the kernel tree. So here I go again: please
> > comment! I have updated the patch to apply to the current upstream git
> > master. ]
> > 
> > Right now, if a process dies all its children are reparented to init.
> > This logic has good uses, i.e. for double forking when daemonizing.
> > However it also allows child processes to "escape" their parents, which
> > is a problem for software like session managers (such as gnome-session)
> > or other process supervisors.
> 
> I think you need to explain why this patch improve gnome-session.
> 
>  - What's happen on current gnome-session. and When?

If a child of a supervisor daemon such as g-s does a double fork (and
unfortunately most existing user daemons do), then that supervisor
deaemon will be unable to monitor that child anymore, i.e. do
something when it dies, such as restarting it, or tearing the session
down, or doing something when it segfaults and so on.

Also, if g-s itself dies, clients that escaped it via double-forking
will stay around even if PR_DEATHSIG is used. With this patch applied
PR_DEATHSIG will work for them too because child processes cannot
escape their parents anymore if the parent wants that. And
getrusage(RUSAGE_CHILDREN) will start to return useful results in g-s
too.

Also, as a minor side-effect the output of "ps xawf" or similar tools
becomes much more useful since processes belonging to a session will
actually show up as children of g-s in the tree instead of as
unattached processes.

Right now, only init itself can do process supervising properly, since
it will be getting the SIGCHLD for those processes that escaped their
parents by double forking. With this patch I want to extend this
power to non-init supervisor daemons, such as g-s.

Also, this makes it easier to write and test init daemon because you
can run them as PID != 1 and still get very similar functionality
regarding SIGCHLD.

>  - After the patch, Which behavior will be changed?

For normal processes, nothing. And for those which use this new
PR_SETACNHOR call the children won't be able to escape them anymore
via a double fork. Or as I already tried to explain:

> > This patch adds a simple flag for each process that marks it as an
> > "anchor" process for all its children and grandchildren. If a child of
> > such an anchor dies all its children will not be reparented to init, but
> > instead to this anchor, escaping this anchor process is not possible. A
> > task with this flag set hence acts as little "sub-init".

>  - Why do you think gnome-session can ignore old kernel?

Did I say that?

On new kernels supervisor daemons can make use of this and children
won't be able to escape them. On old kernels they cannot and children
will continue to escape them. But uh, that should be fine. So on newer
kernels g-s can supervise all user daemons nicely, and on old kernels
we continue with the status quo. That should be fine.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

  reply	other threads:[~2010-02-03  9:54 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-02 12:04 [PATCH] exit: PR_SET_ANCHOR for marking processes as reapers for child processes Lennart Poettering
2010-02-03  8:24 ` KOSAKI Motohiro
2010-02-03  9:53   ` Lennart Poettering [this message]
2010-02-03 15:31 ` Américo Wang
2010-02-03 17:49   ` Lennart Poettering
2010-02-05  9:54     ` Américo Wang
2010-02-11 10:21       ` Kay Sievers
2010-02-04 15:42 ` Kay Sievers
2010-02-04 20:59   ` Kay Sievers
2010-03-04 14:08 ` Oleg Nesterov
2010-03-04 22:14   ` Roland McGrath
2010-03-05 18:51     ` Kay Sievers
2010-03-05 19:18       ` Roland McGrath
2010-03-06  0:24         ` Lennart Poettering
2010-03-09  0:45           ` Ray Lee
2010-03-09 13:19             ` Oleg Nesterov
2010-03-06  0:20     ` Lennart Poettering
2010-03-08 23:11       ` Roland McGrath
2010-03-05  4:47   ` KOSAKI Motohiro
2010-03-05 18:55     ` Kay Sievers
2010-03-06  0:16   ` Lennart Poettering
2010-03-11  4:14     ` Eric W. Biederman
2010-03-11  7:56       ` KOSAKI Motohiro
2010-12-20 14:26 ` Scott James Remnant
2010-12-20 14:51   ` Kay Sievers
2010-12-21  9:56   ` Lennart Poettering
2010-12-21 12:05     ` Scott James Remnant
2010-12-23 15:44       ` Lennart Poettering
2010-12-23 16:00         ` Scott James Remnant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100203095339.GA10050@tango.0pointer.de \
    --to=mzxreary@0pointer.de \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).