linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakob Oestergaard <jakob@unthought.net>
To: Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>
Cc: David Schwartz <davids@webmaster.com>,
	Mike Fedyk <mfedyk@matchmail.com>,
	Hank Leininger <hlein@progressive-comp.com>,
	linux-kernel@vger.kernel.org
Subject: Proposal (was: Why are exceptions such as SIGSEGV not logged)
Date: Tue, 19 Aug 2003 10:31:32 +0200	[thread overview]
Message-ID: <20030819083131.GB28162@unthought.net> (raw)
In-Reply-To: <200308190654.h7J6sIL07040@Port.imtp.ilyichevsk.odessa.ua>

On Tue, Aug 19, 2003 at 09:54:17AM +0300, Denis Vlasenko wrote:
> On 19 August 2003 01:39, David Schwartz wrote:
...[snip]...
> > 	This is a perfectly sensible thing for a program to do with well-defined
> > semantics. If a program wants to create a child every minute like this and
> > kill it, that's perfectly fine. We should be able to do that in the default
> > configuration without a sysadmin complaining that we're DoSing his syslogs.
> 
> I disagree. _exit(2) is the most sensible way to terminate.
> 
> Logginh kernel-induced SEGVs and ILLs are definitely a help when you hunt
> daemons mysteriously crashing. This outweighs DoS hazard.


Ok guys - we will never come to an agreement on what would be the
sensible thing to do.

For good reasons, too: the purposes and uses of the systems out there,
and the minds of the people administering them, will be as different as
anything.

This reminds me of the "core naming wars", the "vm overcommit wars", and
other "big" (in the minds of people) issues that were solved to
everyones satisfaction with an entry in /proc.

May I suggest:
  /proc/sys/kernel/log_signals

Semantics:  Numbers can be written to log_signals - these are signal
numbers that will cause a log entry to be written, when the given signal
is delivered. The file can be read, in which case it will list the
signal numbers that cause log entries to be written.

Examples:

]$ cat /proc/sys/kernel/log_signals
   4
   7
]$ echo +15 > /proc/sys/kernel/log_signals
]$ cat /proc/sys/kernel/log_signals
   4
   7
   15
]$ echo -4 > /proc/sys/kernel/log_signals
]$ cat /proc/sys/kernel/log_signals
   7
   15
]$

Possible extension:

]$ echo '*' > /proc/sys/kernel/log_signals
]$ cat /proc/sys/kernel/log_signals
 ... lists all signals ...
]$ echo '-*' > /proc/sys/kernel/log_signals
]$ cat /proc/sys/kernel/log_signals
]$


In my oppinion it does not make sense to distinguish between signals
sent from process to process, and from kernel to process.  Some garbage
collectors, for example, depend on the kernel sending the SIGSEGV and do
their own handling of that - while for many other processes that
situation indicates a problem.   Better to handle that kind of thing in
user space log auditing tools.

An implementation of the above is left as an exercise for the reader  :)

Comments?

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

  reply	other threads:[~2003-08-19  8:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-18 20:50 Dumb question: Why are exceptions such as SIGSEGV not logged Hank Leininger
2003-08-18 21:02 ` Mike Fedyk
2003-08-18 21:18   ` Hank Leininger
2003-08-18 21:25     ` Mike Fedyk
2003-08-18 22:12   ` William Lee Irwin III
2003-08-18 22:39   ` David Schwartz
2003-08-18 22:44     ` Mike Fedyk
2003-08-18 22:53       ` David Schwartz
2003-08-19  6:54     ` Denis Vlasenko
2003-08-19  8:31       ` Jakob Oestergaard [this message]
2003-08-19 14:52       ` Valdis.Kletnieks
2003-08-19 18:51       ` David Schwartz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030819083131.GB28162@unthought.net \
    --to=jakob@unthought.net \
    --cc=davids@webmaster.com \
    --cc=hlein@progressive-comp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mfedyk@matchmail.com \
    --cc=vda@port.imtp.ilyichevsk.odessa.ua \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).