lkml.org 
[lkml]   [2006]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] emit logging when a process receives a fatal signal
From
On Sun, Nov 19, 2006 at 12:24:14AM +0100, Jan Engelhardt wrote:
>
> On Nov 18 2006 21:51, Oleg Verych wrote:
> >On Sat, Nov 18, 2006 at 08:30:02PM +0100, Jan Engelhardt wrote:
> >> >Then, who you think prints that "Killed" or "Segmentation fault"
> >> >messages in *stderr*?
> >> >[Hint: libc's default signal handler (man 2 signal).]
> >>
> >> Please enlighten us on how you plan to catch the uncatchable SIGKILL.
> >
> >Here's question of getting information. Collecting information is
> >possible by `waitpid()' from parent process as Miquel noted.
>
> Yes, that is true. However that would involve adding support for This
> Situation to the parent process. Which is where it becomes tricky. Patch
> /sbin/init, in case the daemon runs like everything else. Or patch
> xinetd, in case it is run from within that. Or, ...
> The 'problem' with the waitpid solution is that you would need to
> patch every possible parent that may become the owner of The Sigkilled
> Target.

I think this is pure userspace admin issue, one wrapper shell script
for not programmers.

I'm not sure about init, you've told. For example, in Debian daemons are
run by start-stop-daemon function in LSB package. And in proposed LSB
standard <http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/>
portable start_daemon, killproc, pidofproc funcions are described.
____
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-11-19 08:11    [W:0.048 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site