linux-kernel - Re: [PATCH] Print sysrq-m messages with KERN

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20070102180354.GA892@thunk.org>
Date:	Tue, 2 Jan 2007 13:03:54 -0500
From:	Theodore Tso <tytso@....edu>
To:	Alan <alan@...rguk.ukuu.org.uk>
Cc:	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Print sysrq-m messages with KERN_INFO priority

On Tue, Jan 02, 2007 at 10:33:32AM +0000, Alan wrote:
> On Mon, 1 Jan 2007 23:37:43 -0500
> Theodore Tso <tytso@....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
-
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/