lkml.org 
[lkml]   [2019]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v2] sysctl: Add panic-fatal-signals
On Wed, Jan 30, 2019 at 3:49 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> On Mon, Jan 28, 2019 at 10:05:45AM -0800, Andrew Morton wrote:
> > On Mon, 28 Jan 2019 09:49:59 +0100 Vincent Whitchurch <vincent.whitchurch@axis.com> wrote:
> > > --- a/init/Kconfig
> > > +++ b/init/Kconfig
> > > @@ -1242,6 +1242,20 @@ config SYSCTL_SYSCALL
> > >
> > > If unsure say N here.
> > >
> > > +config SYSCTL_PANIC_FATAL_SIGNALS
> > > + bool "panic-fatal-signals sysctl" if EXPERT
> > > + depends on PROC_SYSCTL
> > > + help
> > > + If you say Y here, a kernel.panic-fatal-signals sysctl will be
> > > + offered. If this sysctl is turned on, the kernel will panic if any
> > > + userspace process receives a fatal signal which would trigger a core
> > > + dump.
> > > +
> > > + When used together with kernel core dumps, this can be useful for
> > > + debugging some system-wide problems, primarily on embedded systems.
> > > +
> > > + If unsure, say N.
> >
> > I suggest that the Kconfig help and the forthcoming documentation
> > should clearly explain the dangers of enabling this!
>
> And so, should default to n.
>
> Luis

Hmm, why can't this be a core dump helper?
Such as:

#!/bin/sh
# Usage:
# echo "|/root/crash.sh %p %e %s" > /proc/sys/kernel/core_pattern

PID="$1"
COMM="$2"
SIGNAL="$3"

echo "$COMM ($PID) died by signal $SIGNAL, killing kernel" > /dev/kmsg
echo c > /proc/sysrq-trigger

--
Thanks,
//richard

\
 
 \ /
  Last update: 2019-01-30 16:04    [W:0.106 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site