From: Scott James Remnant <scott@canonical.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Roland McGrath <roland@redhat.com>,
lkml <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC][PATCH] Notify init when processes are reparented to it
Date: Mon, 29 Dec 2008 07:21:11 -0800 [thread overview]
Message-ID: <1230564071.4664.8.camel@wing-commander> (raw)
In-Reply-To: <20081229132305.GA31210@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]
On Mon, 2008-12-29 at 14:23 +0100, Oleg Nesterov wrote:
> On 12/29, Scott James Remnant wrote:
> >
> > On Sun, 2008-12-28 at 14:01 -0800, Roland McGrath wrote:
> >
> > > I'm highly skeptical that this is a desireable feature at all, and
> > > certainly I find the abuse of siginfo_t.si_status here extremely
> > > questionable. I think we need a clear explanation of what problems
> > > the feature is intended to address.
> > >
> > Did the original e-mail not address this?
>
> Do you mean
>
> [RFC] Notify init when processes are reparented to it
> http://marc.info/?l=linux-kernel&m=123038049428388
>
> ?
>
> I am not sure I really understand the problem. And thus I can't
> understand how this patch can help.
>
No problem ;) like anything, it's only ever perfectly clear to the guy
who wrote it - and everyone else wonders what he's going on about :p
> > We want to be able to supervise daemons.
>
> What do you mean?
>
> > Later on, 1002 will die and init will receive SIGCHLD for it.
> >
> > Unfortunately neither the 1001 or 1002 processes are known to init, even
> > though they are original children of the process it spawned (1000), for
> > init to be notified about them - this has been forgotten.
>
> Ok, with this patch /sbin/init knows that 1002 is a descendant
> of apache(1000) which was spwaned by init. What can init do
> with this info?
>
Fundamentally init would now know that the apache service terminated,
and with what exit code or by what signal.
Right now, all we know is that a process terminated (and why) - we can't
link that back to a service in any kind of foolproof manner.
With the ability to do that, when the apache service dies, we can log
that in a more useful manner (including marking the service as down) -
but most importantly, we can respawn it!
This is something we can't do with processes that daemonise right now.
Scott
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2008-12-29 15:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-27 11:42 [RFC] Notify init when processes are reparented to it Scott James Remnant
2008-12-27 11:44 ` [RFC][PATCH] " Scott James Remnant
2008-12-28 9:20 ` Oleg Nesterov
2008-12-28 22:01 ` Roland McGrath
2008-12-29 11:50 ` Scott James Remnant
2008-12-29 13:23 ` Oleg Nesterov
2008-12-29 15:21 ` Scott James Remnant [this message]
2008-12-29 15:57 ` Oleg Nesterov
2008-12-29 17:36 ` david
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=1230564071.4664.8.camel@wing-commander \
--to=scott@canonical.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=roland@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.