Re: [PATCH] emit logging when a process receives a fatal signal

[Mikael Pettersson <mikpe@it.uu.se>]

On Sat, 18 Nov 2006 02:09:46 +0100, Folkert van Heusden wrote:
>I found that sometimes processes disappear on some heavily used system
>of mine without any logging. So I've written a patch against 2.6.18.2
>which emits logging when a process emits a fatal signal.
>
>Signed-off-by: Folkert van Heusden <folkert@vanheusden.com>
>
>--- linux-2.6.18.2/kernel/signal.c	2006-11-04 02:33:58.000000000 +0100
>+++ linux-2.6.18.2.new/kernel/signal.c	2006-11-17 15:59:13.000000000 +0100
>@@ -706,6 +706,15 @@
> 	struct sigqueue * q = NULL;
> 	int ret = 0;
> 
>+	if (sig == SIGQUIT || sig == SIGILL  || sig == SIGTRAP ||
>+	    sig == SIGABRT || sig == SIGBUS  || sig == SIGFPE  ||
>+	    sig == SIGSEGV || sig == SIGXCPU || sig == SIGXFSZ ||
>+	    sig == SIGSYS  || sig == SIGSTKFLT)
>+	{
>+		printk(KERN_WARNING "Sig %d send to %d owned by %d.%d (%s)\n",
>+			sig, t -> pid, t -> uid, t -> gid, t -> comm);
>+	}
>+
> 	/*
> 	 * fast-pathed signals for kernel-internal things like SIGSTOP
> 	 * or SIGKILL.

NAK.

1. It lets any user DOS the system.
2. Your definition of "fatal" signals is wrong. Several of these
   signals can be caught, and user-space sometimes does that for
   good reason. FPE and SEGV are definitely often caught, BUS and
   ILL may be caught, and I suspect TRAP to be common in debugging
   sessions.
3. It puts policy in the kernel. Policy decisions belong in user-space.
   In this case, the policy decision is whether this type of logging
   is desired for a given process or not.
4. If this is about detecting the loss of specific processes
   (network services say), then the problem can be solved in
   user-space by using a separate monitor process, or by
   controlling the processes via ptrace.

At a minimum, the logging needs to be conditionalised on a
per-process setting, and it should also be delayed until the
point where a signal causes a process to be killed.

/Mikael