Re: [PATCH] Print sysrq-m messages with KERN_INFO priority

[Theodore Tso <tytso@mit.edu>]

On Tue, Jan 02, 2007 at 10:33:32AM +0000, Alan wrote:
> On Mon, 1 Jan 2007 23:37:43 -0500
> Theodore Tso <tytso@mit.edu> wrote:
> > > Is this patch a consistency thing?
> > 
> > The goal of the patch was to avoid filling /var/log/messages huge
> > amounts of sysrq text.  Some of the sysrq commands, especially sysrq-m
> > and sysrq-t emit a truly vast amount of information, and it's not
> > really nice to have that filling up /var/log/messages.  
> 
> I find it extremely useful that it ends up in /var/log/messages so that I
> can review the dump later. Often the first glance through a set of dumps
> on things like a process deadlock don't reveal the right information and
> you need to go back and look again.

Maybe it's something that should be configurable?

Usually I end up configuring a separate line in /etc/syslog.conf so
that it gets logged to a file --- but not one which is subject to the
same retention period as /var/log/messages.  The reason why this
becomes an issue for me is that unfortunately, there is some
information displayed by alt-sysrq-m that can't be found any other way
--- it's not available in /proc/slabinfo, /proc/meminfo, etc.  So I
have a script which I use when I'm trying to debug obscure customer
problems which does an "echo m > /proc/sysrq-trigger" every 15
minutes, so I can gather information that might help point towards the
problem. 

Granted, most of the time the additional information shown by sysrq-m
isn't necessary, but I usually get called in after the other Level 3
support folks haven't been able to solve the problem, so like the
Richard Feymenn story, it's a tool that everyone else doesn't have in
their toolbox, so it often solves problems that others haven't been
able to figure out.

So maybe the right solution is either to make the priority level
configurable, or perhaps better, making the sysrq-m information
available via either /proc or /sys?

						- Ted