"The Linux Gazette...making Linux just a little more fun!"

Console Goes Comatose After a Few Days

From kodancha on Sun, 30 Jan 2000

sir

i have installed redhat linux 6.1 on piii hardware with fire walls.IT works fine.But every 3-4 days i have to reboot the system because of the following.

Sytems will not take any command.When i type any thing cursor moves but no char appears on the screen.Even cntrl-alt-del is also not working.But all oher clients connected this server has got no problem.I tryied stty sane ,cntrl -c etc but it is not respondig.Can u help me

gjkodancha

Well, you description doesn't give me much to go on.

Is this in X? Are you using a kernel with frame buffer (graphics driven text mode) console support?

Try building a new kernel. Leave the system in text mode and disable any "VESA VGA Graphics" support in the kernel (in menuconfig under the "Console Drivers" menu). Be sure to enable the "Magic SysRq Key" under "Kernel Hacking." Read the docs about this "Magic SysRq" in the /usr/src/linux/Documentation/sysrq.txt file.

Now, after you've built and installed the new kernel, when you reboot with it, use runlevel 3 (Red Hat: text mode multi-user mode) rather than runlevel 5 (multi-user with GUI/xdm login mode).

If the console seems to go comatose again, try using some of the Magic SysRq keys, particularly the p (processor status), t (task list) and m (memory status) diagnostics, and the k and r keys to kill everything on a given console and to "reset" the keyboard driver.

A couple of other things you can do:

Edit /etc/syslog.conf and add a line like:

*.* /dev/tty12

... (and restart your syslog daemon). This will copy all syslog messages to your twelfth virtual console. When you leave your system unattended, switch to that VC. If it appears comatose when you get back, look at the messages at the end.

When you restart your system, look at the tail of the /var/log/messages file. That's where most system warnings and errors are logged.

Also you can try logging in via ssh (or telnet, rlogin or some other insecure protocol) and using the commands: chvt 1 or chvt 2 ... to force the console to switch to another VC. See if that works.

You can also run commands like

stty sane < /dev/tty1

And:

setterm -reset > /dev/tty1

(note: the redirection operator on my stty command is NOT backwards. stty performs ioctl() calls on it's input device while setterm words on it's output file descriptor. It looks weird but stty was written a long time ago and it actually made sense back then).

I've had cases where I could revive a console (from a crashed X session or a wacked out SVGAlib program failure) by running startx (from a remote session, even from a serial login. That works sometimes (since the X server has to reset quite a bit of the video and keyboard state as it starts).

These kinds of console oddities are pretty rare. It's usually the result of some buggy program that's running with root privileges or some buggy driver (which naturally is running with system/kernel level access to the hardware). It could be a bit of flaky hardware, too. It would be good to figure out what is doing this. However, if this is set up as a server, it may be that you don't need the console all that much. You can treat it like a "headless" system if you need to.

If you do decide to switch out hardware, try a cheap replacement video card. Under Linux, in server applications there is no point to using a high end video card. Meanwhile the high end video cards are most likely to have the cutting edge technology and the highest chance of conflict with other system components. Also make sure that any "Plug and Pray" (PNP) settings are disabled in your ISA peripherals and BIOS/CMOS.

If you think it's software then try attaching strace to various processes that are bound to your console. See if there's some oddity to the system calls they're making before the lockup.

(Read the strace man page to understand a bit more about this. Don't even bother if you don't know the difference between a system call and a library function. There's a pile of learning curve in that direction).

Copyright © 2000, James T. Dennis
Published in The Linux Gazette Issue 51 March 2000

HTML transformation by Heather Stern of Tuxtops, Inc., http://www.tuxtops.com/

					1	2	3	5
				5	6	7	8	9
10	11	12	13	14	15	16	17
18	19	20	21	22