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.
>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/
