On Sat, Nov 18, 2006 at 08:30:02PM +0100, Jan Engelhardt wrote: > > On Nov 18 2006 02:38, Oleg Verych wrote: > >On Sat, Nov 18, 2006 at 03:04:13AM +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. > >> > > Why not to patch default signal handlers in glibc, to have not only > >> > > stderr, but syslog, or /dev/kmsg copy of fatal messages? > >> > Afaik when a proces gets shot because of a segfault, also the libraries > >> > it used are shot so to say. iirc some of the more fatal signals are > >> > handled directly by the kernel. > > > >Kernel sends signals, no doubt. > > > >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. That man above, gave me impression, that SIG_DFL can not be changed in case of KILL and STOP signals, what yields to "The signals SIGKILL and SIGSTOP cannot be caught or ignored." Implementation of such no-action can be different. In case if kernel just stops processing of task with STOP, breaks with KILL, without giving a chance to flush any pending data OK, if this is an assembler prorgam with just data segment and no infrastructure at all. But i think (didn't read anything), it is bad, if there's libc with standard stream I/O buffers and no callback is possible. > > -`J' > -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
