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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.61.0611191144550.24349@yvahk01.tjqt.qr>
Date:	Sun, 19 Nov 2006 11:47:58 +0100 (MET)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	Oleg Verych <olecom@...wer.upol.cz>
cc:	Folkert van Heusden <folkert@...heusden.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] emit logging when a process receives a fatal signal


On Nov 19 2006 07:13, Oleg Verych wrote:
>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.

But usually the start wrapper will succeed, and the daemon will 
eventually get reparented to init. At least this is the case in 
LSB-compliant distros like opensuse and fedora.


	-`J'
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/