Is there a way to shove kernel-panic to the screen?

Question

Can a user shove the cause of a kernel panic to the screen?

The cause of the panic? That's generally a kernel bug, or a hardware failure—what do you mean by shove that to the screen? — derobert, Sep 19 '13 at 16:32
I'm running X11 as are most individuals running linux, I want to push the cause of the panic or the dump itself to screen. — Cole Busby, Sep 19 '13 at 16:43
What screen? Do you want a pop-up to appear? That will depend on your DE. One possibility would be to use conkyand have it show you dmesg | tail output. I could post an answer explaining how if that would work for you. — terdon, Sep 19 '13 at 17:05
@terdon I have been trying to find out how to use conky and that I believe would be the best solution if you could. — Cole Busby, Sep 19 '13 at 17:11
Why is this actually important to you? If you're having kernel panics, don't try to "improve" the symptom, but fix the underlying cause - update your kernel if it's outdated, or replace the hardware. — Martin von Wittich, Sep 19 '13 at 19:06
@MartinvonWittich $ and not the linux verison. I dont have the monetary resources to replace the hardware, so I'm attempting to salvage what I can. And I haven't tried a different kernel yet. Also, I like to tinker with my system. Besides the fact that fixing the correct hardware would be nice to know, process of elimination and that. — Cole Busby, Sep 19 '13 at 19:10
What Linux version are you using (uname -a)? Have you tried to run memtest86 to identify hardware issues? — Martin von Wittich, Sep 19 '13 at 19:26
You may want to have a look at xconsole. It's ancient (if you want to make it less ugly, change the font, etc., you have to deal with .Xresources...) but this is exactly what it is for -- it will display whatever syslog sends to /dev/console, which is usually just serious stuff (error+). Less mess than tailing dmesg (and less chance of missing important stuff amidst all the chaff). Someone should write a snazzy GTK replacement -- pretty sure it's as simple as reading from /dev/console. I can add details in a proper answer when I get home. — goldilocks, Sep 19 '13 at 19:59

score 8 · Accepted Answer · answered Sep 19 '13 at 17:27

Linux does dump panics to the screen...depending on your definition of the screen.

What Linux actually does is dump to the system console. Often this is the screen, but can be the serial console (or elsewhere) instead.

However, most people are running X on their desktops. Which means that the console is not on the screen, the frame buffer is. You would need to have Linux dump to the frame buffer in this case and I suspect that this is really what you're seeking.

Lucky for you, there's a project working on this over at Ubuntu. I don't know how far along the project is, but it looks promising and that's where you should start.

Actually, linux dumps everything to syslog, and syslog sorts it out. Have a look in /etc/[r]syslog.conf -- the panic stuff is priority emerg and that goes to * -- all active ttys. But you could send it to anything (guess what /dev/xconsole is for?) — goldilocks, Sep 19 '13 at 20:08

score 2 · Answer 2 · edited Apr 13 '17 at 12:36

2

DISCLAIMER: I have posted this answer because you said you wanted conky. If you are talking about real kernel panics and not just error messages and the like, this won't work because, well, the kernel will be too busy panicking for you to be able to do anything else.

conky should be in your distribution's repositories, so installing it is straightforward. Once you have done so, you will need to create a ~/.conkyrc file. Mine is kind of complicated, this is a minimal working .conkyrc that displays the last 8 lines of dmesg in a nicely formatted way:

    double_buffer yes
     background yes
    update_interval 1
    total_run_times 0
    own_window yes
    own_window_type desktop
    own_window_transparent yes
    own_window_hints undecorated,below,sticky,skip_taskbar,skip_pager
    minimum_size 230 5
    maximum_width 230
    gap_x 1365
    gap_y 40

TEXT

${execpi 3 dmesg |tail -n8}

That looks kind of ugly though, so I have a script that formats the output, folding long lines and indenting to group lines from the same message together. To use it save the script below as something like ~/bin/conkyLogging, make it executable chmod a+x ~/bin/conkyLogging and change that last line to

 ${execpi 3 dmesg |tail -n8 | /home/USERNAME/scripts/conkyLogging.pl}

The script is:

#!/usr/bin/env perl
my $lim=32;
my @a;
while(<>){/.*?\]\s*(.+)$/;
 push @a,$1;
}
my $k;
for($n=$#a;$n>=0; $n--){
    $_=$a[$n];
    @c=split(/[\s]+/);
    @b=split(//);
    my $k=0;
    my $kk=0;
    print "    ";
    for($i=0;$i<=$#b; $i++){
    $_=$b[$i];
    if (/^\s+$/){
        $k+=length($c[$kk+1]);
        $kk++ ;
    }
    if($k>$lim){
        s/([=,\-\s])/$1\n\t  /;
        $k=0;
    }
    print STDOUT;
    }
    print STDOUT "\n";
}

For more information on the various conky variables and how to set up your .conkyrc see here and here.

edited Apr 13 '17 at 12:36

Community

1

answered Sep 19 '13 at 17:29

terdon

242,166

I'd say that if the intention is to handle a kernel panic in any way, for example displaying it on X11 (which is apparently what the OP is trying to do), then anything in the userland won't do the trick. – Martin von Wittich Sep 19 '13 at 17:40
For kernel panics this is hardly usable, I'm afraid - once you get a panic, user processes are stopped. Some kernel subsystems finish what they're doing but that's as far as it gets - kernel panic is a dead end. – peterph Sep 19 '13 at 17:42
@MartinvonWittich if this is a proper kernel panic I guess it won't but there is no way (AFAIK) to display that since you will be fried anyway. – terdon Sep 19 '13 at 17:42
@peterph yes, but the OP wanted conky (see my comments to the question). As far as I know, if you have a kernel panic you'll need to reboot and there is no way of displaying it so I figure the OP means something different than a bona fide kernel panic. – terdon Sep 19 '13 at 17:43
@terdon: yeah, in userland there's no way. One could modify the kernel though so that it will at least switch to a VT before displaying the panic, like Windows does it with bluescreens. Maybe Linux is actually doing than... I don't know, I haven't seen a kernel panic in a long time :) – Martin von Wittich Sep 19 '13 at 17:45
I upvoted this answer because it will be helpful as I'm not sure if it is a bona fide Kernel Panic, I assume it is because no matter of mouse manipulation or keyboard smashing will resurrect the system. Again, to reiterate, even if this does not turn out to rectify the issue it is helpful to me regardless thus he receives my upvote. Thank you @terdon. – Cole Busby Sep 19 '13 at 17:56
@MartinvonWittich If you know of a way to switch to the VT (I assume this is short for a tty console) on panic that would be lovely to know. – Cole Busby Sep 19 '13 at 17:57
@ColeBusby I'm afraid I don't. – Martin von Wittich Sep 19 '13 at 19:00
@ColeBusby it's not as easy as it might sound - first, it would have to be done in the kernel and second it might interfere with modesetting (since the Linux console might be running in different mode than X). – peterph Sep 19 '13 at 19:49

score 1 · Answer 3 · edited Apr 13 '17 at 12:36

Presumably, by shove the cause to the screen you mean force the kernel to dump information on the screen.

I'm no expert by far, but as far as I know, there is no way. When a kernel panic occurs it dumps the information to the console and then crashes. That means that there's no way to do anything after the panic because nothing's running anymore.

If you're on an actual tty (not an xterm), I believe you'll see information. But otherwise you're out of luck. What is a "kernel panic"? seems to have some information on this.

score 1 · Answer 4 · answered Sep 27 '13 at 15:10

Syslog is the facility that controls where logging output, including dmesg stuff, kernel panics, etc., gets sent. There are a few different syslog daemons in common use, but I believe they are all more or less the same for the purposes of this discussion.

The syslog daemon has a configuration file in /etc. Traditionally, this is syslog.conf, but for the alternate rsyslogd (used with modern .rpm based distros), for example, it's rsyslog.conf. Without getting too into how this configuration works, a few directives usually in there are worth considering here:

# Emergencies are sent to everybody logged in.
*.emerg                         *

# Log all kernel messages to the console.
kern.*                                                 /dev/console

The first one is why certain serious errors will appear on all ttys. However, it does not include GUI terminals, meaning you won't see anything in X.

The second one sends all messages from the kernel to /dev/console^*, which is usually synonymous with /dev/tty0, which is generally understood to be "the current virtual console", although that still won't be a GUI console.

You can set the device to use as the console with a kernel boot parameter, e.g., console=/dev/tty6. You can probably get the current device with cat /sys/devices/virtual/tty/console/active.

There is a venerable (as in, pre-internet era) GUI app called xconsole which will display the messages sent to /dev/console. It does not use modern widget sets, unfortunately, and if you want to configure it, you have to use an Xresources file:

XConsole*text.width:          1000
XConsole*text.height:         300
XConsole*background:          #cccccc
XConsole*font:                -adobe-helvetica-medium--normal-*-14-*-*-*-*-*-iso8859-1

You'll probably need at least the font to make it readable.

This will allow you to see kernel panic messages the same as you would in a VT. If you put it on some back corner desk and the system freezes up, there's a good chance you can still switch to it (although, you could also try switching to a VT or killing X).

You could also specify a fifo or socket in syslog.conf and implement your own method of getting messages in X.

^*Debian derived systems also have a /dev/xconsole device and this will be referenced in their syslog.conf.

score 0 · Answer 5 · answered Sep 19 '13 at 19:55

If you are experiencing panics more than just very seldomly, probably your best choice is having another (probably low-power) device connected to it and log to it either via serial cable or netconsole. Netconsole has the obvious advantage of using another device that is already running anyway (you can log even to a home router if need be).

Is there a way to shove kernel-panic to the screen?

5 Answers5