Can a user shove the cause of a kernel panic to the screen?
5 Answers
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.

- 39,666
- 4
- 75
- 104
-
1Actually, linux dumps everything to syslog, and syslog sorts it out. Have a look in
/etc/[r]syslog.conf
-- the panic stuff is priorityemerg
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
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.
-
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 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
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.
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.

- 87,661
- 30
- 204
- 262
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).

- 30,838
conky
and have it show youdmesg | tail
output. I could post an answer explaining how if that would work for you. – terdon Sep 19 '13 at 17:05uname -a
)? Have you tried to runmemtest86
to identify hardware issues? – Martin von Wittich Sep 19 '13 at 19:26xconsole
. 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