Kill X in the event of a panic, or make it drop back to the console

andersbo87

andersbo87

Hey! Earlier on today I installed X11 and GNOME on my FreeBSD 9 laptop. For the sake of testing how X is "reacting" to a kernel panic, I decided to type [cmd=]sudo kill -11 1[/cmd] to force a panic. I know this is dangerous, but since I'm on a laptop, I really don't expect a lot of uptime, anyhow. Anyway, I've configured my kernel to include DDB as to easily make create crash dumps in the event of a panic, which I tested from within the system console, as well as enabling crash dumps in /etc/rc.conf. Dumping cores went well when my system panics while it is in the system console, but when I reproduced the same panic in X, the system froze, and typing ctrl+alt+F1, etc to get back to the console, did not work.

My question is if it is possible to either kill X in the event of a panic or make it drop back to the console as to let the user dump a crash core and reboot the system? If so, how can I achieve that? I'm quite new to this system.

Thanks in advance. :-)
 
I'm of the opinion that enabling SUJ on your filesystems will lessen the number of panics, AND enable X to recover from them more often. YMMV, but I don't know how I got along without it... (No definitive answer though.)
...
Might as well add, I had a backup script (rsync) using very large SUJ'd partitions. Never any problem with the --bwlimit=2000 on lesser-sized ones, but on one particular disk, it is best run in "menu 6 -- safe mode" only (Not enough memory for the journal stuff, as evidenced by longer boot times.)
 
andersbo87 said:
My question is if it is possible to either kill X in the event of a panic or make it drop back to the console as to let the user dump a crash core and reboot the system? If so, how can I achieve that? I'm quite new to this system.
Click to expand...

You need to think this through: what is a panic? A panic implies that something bad happened, interrupting normal operations of the OS and its functions. Thus, you cannot be certain that any OS function will work, or work correctly after a panic. Unless you can predict panics in advance, I think you will have a hard time getting "switch back to console" or "kill Xorg" working after a panic.

A remote connection from another machine might work, depending on the panic and the connection (ssh, serial console, firewire console).
 
One of the nice things about KMS on Linux is that the you can can actually have the panic displayed on the screen. I don't know if this is true on FreeBSD as well (with the intel KMS/GEM code in place), but I have my doubts since console switching isn't even supported there.

Adam
 
Thanks for your help, guys.

On a Mac, when booting OS X in verbose mode, either by pressing cmd+v when booting, or typing sudo nvram boot-args="-v", the system prints the actual panic message, kernel version, debugging information, the FreeBSD process that caused the panic as well as system uptime in nanoseconds "on top of" the desktop. If you enable "Restart automatically if the computer freezes", the system automatically reboots a few seconds later. During the reboot process, the panic message is saved to a text file located in the /Library/ folder.

And, when the system has rebooted and the user is logged in, Mac OS asks if the user wants to send the panic report to Apple. So panic handling seems to vary from OS to OS. :-)
 
adamk said:
but I have my doubts since console switching isn't even supported there.

Adam
Click to expand...

By "console switching", do you mean changing from i.e. /etc/ttyv1 to /etc/tty2, etc, which is achieved by pressing ctrl-alt-F2, ctrl-alt-F3, etc, or am I getting you wrong now?
 
No, you have it correct. Console switching (once X starts) like that does not work if you are using the new GEM/KMS code being worked on.
 
You must log in or register to reply here.
Back
Top