Messages in this thread | | | From | Richard Weinberger <> | Date | Wed, 30 Jan 2019 16:02:36 +0100 | Subject | Re: [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
| |