[lkml]   [2007]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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 <> 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

    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-01-02 19:07    [W:0.023 / U:186.444 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site