From: Andrew Morton <akpm@linux-foundation.org>
To: Will Woods <wwoods@redhat.com>
Cc: Neil Horman <nhorman@tuxdriver.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] core_pattern: Add ability for core_pattern to parse arguments when pattern is a pipe
Date: Thu, 26 Jul 2007 12:52:40 -0700 [thread overview]
Message-ID: <20070726125240.645c3322.akpm@linux-foundation.org> (raw)
In-Reply-To: <1185478584.15670.31.camel@metroid.rdu.redhat.com>
On Thu, 26 Jul 2007 15:36:24 -0400 Will Woods <wwoods@redhat.com> wrote:
> On Thu, 2007-07-26 at 11:48 -0700, Andrew Morton wrote:
> > On Thu, 26 Jul 2007 13:40:19 -0400 Neil Horman <nhorman@tuxdriver.com> wrote:
> >
> > > Currently, core dumps can be redirected to a pipe by placing the
> > > following string template in /proc/sys/kernel/core_pattern:
> > > |<path/to/application>
> > > This patch extends this ability, allowing the core_pattern to contain arguments
> > > to be passed as an argv array to the userspace helper application. It also add
> > > a format specifier, %c, which allows the RLIM_CORE value of the crashing
> > > application to be passed on the command line, since RLIMIT_CORE is reduced to
> > > zero when execing the userspace helper
> >
> > This all seems to be getting a bit nutty. Who needs this feature
> > and what will they do with it, etc?
>
> We're using it for doing a system-wide crash dump handler. Currently
> Ubuntu's using it with their Apport tool[1] for this purpose; I'm
> adapting that for Fedora.
Can you please copy the relevant Ubuntu people on the patches then? It
would be valuable to get their input on the proposal.
> The Ubuntu approach requires a kernel patch that adds a bunch of process
> information (process pid, RLIMIT_CORE, etc) to the environment of the
> crash handler[2]. Most of that information can instead be parsed out of
> the ELF headers - which is what I wrote code to do[3]. The problem that
> remains is determining the value of RLIMIT_CORE. (This is used to
> determine whether the user wants a normal corefile, thus retaining
> normal core dump behavior).
>
> As I understand it, getrlimit() won't return the correct values while
> dumping to a pipe. So we need to pass the original RLIMIT_CORE to the
> userspace helper somehow. It seems sensible to pass arguments to a
> userspace program by using argv[]. So there we are.
yup. The changelog should clearly document this new kernel/userspace
interface, please. Things like what the argv format will be, which args
are optional, etc.
> There's probably many other uses for this stuff but that's the specific
> one we're targeting. Does that make sense? If there's an easier way to
> get the original RLIMIT_CORE from inside the crash handler, I'd love to
> hear it.
>
I'm still emerging from the "what the heck is this" state ;)
You need to tell us these things...
next prev parent reply other threads:[~2007-07-26 19:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-26 17:40 [PATCH] core_pattern: Add ability for core_pattern to parse arguments when pattern is a pipe Neil Horman
2007-07-26 18:48 ` Andrew Morton
2007-07-26 19:31 ` Neil Horman
2007-07-26 19:47 ` Andrew Morton
2007-07-26 20:20 ` Neil Horman
2007-07-26 20:35 ` Andrew Morton
2007-07-26 21:46 ` Neil Horman
2007-07-26 19:36 ` Will Woods
2007-07-26 19:52 ` Andrew Morton [this message]
2007-07-26 22:02 ` Jeremy Fitzhardinge
2007-07-27 10:32 ` Neil Horman
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=20070726125240.645c3322.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
--cc=wwoods@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox