So Your Monitor Died

by Charles Curley

Okay, your monitor just died. Now what?

If you are running Linux, or most UNIX variants, and you have taken appropriate precautions, you probably have a simple workaround. This workaround is also useful for the times when your X server crashes, and you need to clean up the carcass. I am writing this on my desktop computer in spite of the fact that my monitor just died. I'm using my laptop as an X terminal. The purpose of this note is to tell you how to do that.

The key is that X, the GUI used on Linux, is layered and designed to operate over a network connection. The program, called the client, transmits commands to the display, called a server, via the internet protocol (IP). The server includes a keyboard and mouse, which also send out to the client via IP. Usually, the client and server are on the same machine. But they don't have to be, and we're going to take full advantage of this fact.

As an extra benefit, you can use this setup to work remotely on your desktop. Say while you are sitting next to the swimming pool working on your tan. Lemonade, anyone?

Logging in Remotely

The first thing to do is set up a suitable method of logging in to your desktop from another computer. Ideally, the other computer should also run X; I use my laptop for this purpose. Both my laptop and my desktop computers run Red Hat 7.1, which has XFree86 4.0.3 and OpenSSH 2.5.2p2.

You can use Telnet or rlogin. They are both insecure, but will do the job. For the gory details, see the Remote X Apps mini-HOWTO, at a Linux Documentation Project server near you. The mini-HOWTO will show you how to set up rlogin or Telnet, and how to arrange things so that the programs on your desktop use your remote computer's X server.

Better, however, is using SSH. SSH has two advantages over rlogin and Telnet. First, it is secure. SSH does not transmit passwords in the clear, a fatal flaw in both Telnet and rlogin. You can run it over the public Internet without worrying about someone snooping your passwords. And it will encrypt your data on the fly.

Second, SSH includes X tunneling, which makes setup easier. It also transparently encrypts the X data that conveys keystrokes, mouse movements and display information.

If you have a fairly recent Linux distribution, you should be all set, as it probably has OpenSSH already on it. You should test the setup before you need to use it. Ensure that X forwarding also works. Make sure you can log in over SSH as root and as your user login.

Since laptops are subject to being stolen (ask the FBI), you should not allow logging from the laptop to your desktop without passwords. For the same reason, don't allow the laptop to log into high security computers like your firewall at all. If you must access the firewall from the laptop, SSH into your desktop, and then SSH into the firewall.

I have put the gory details of my SSH setup on the Net.

Shutting Down Remotely

It is a good idea to know in advance what your computer will do when you shut it down without a monitor. Try it with the monitor and observe what it does.

The command shutdown -h now will halt the computer. With modern motherboards, this may shut the computer off, which is exactly what you want.

If you have an older motherboard, the shutdown process goes to a halted, or locked up, kernel. It does not shut the computer off. You can issue the shutdown command, wait until all the disk activity ends, and then wait a good minute longer, then manually shut down. Or you may reboot (shutdown -r now). If that's the case, observe your computer rebooting. Most will beep once early in the firmware boot process. If your motherboard does that, use that as your signal to turn the computer off.

Der Tag

Comes the day: your monitor has just emitted some rude noises and died. What now? Leave the desktop computer running; mine provides DNS, DHCP and other services on my office network. Carefully unplug the monitor. If you need to use the desktop computer, you already know how to log in remotely.

Suppose you take your monitor out to the computer shop, and they examine it. While they're doing that, you use the laptop for normal access to the desktop, just as you have been all along.

If you are really lucky, you get the monitor back, repaired, plug it in, and resume normal operations. Don't forget to gracefully shut down all the open applications and log out of the SSH session on the laptop before you switch back to your desktop.

If you are almost that lucky, the monitor is still under warranty, and the replacement shows up in a few days. Cool. Leave the desktop running, and use the laptop.

If you aren't that lucky, you have to shell out for a new monitor. It is probably not a good idea to just plug in the new monitor and run it, due to variations in monitors. Now what?

Preparing for a New Monitor

First, log in to the desktop. If you are already logged in, shut down any applications you are running.

The first thing to do on the desktop is to make sure your computer won't boot to graphics mode, run level 5. If it does, change it to boot to run level 3. Edit /etc/initab. Red Hat versions of this file tell you exactly what to do, and other versions operate similarly. Find a line that looks like this:

id:5:initdefault:

Change the 5 to a 3. N.b: Make no other changes, or you may render your system unbootable!

Next, just in case, copy your XF86Config* file(s) to backups. Later on, you will overwrite these. On Red Hat systems, they are in /etc/X11. If they aren't there, try locate XF86Config.

Before you shut down the desktop, you may also need to adjust the console video mode. If you have set a VGA option in your lilo.conf (e.g., append="vga=5"), you may want to change it to something a bit more conservative. You can comment it out, or change it to "vga=ask" so you can select a suitable mode at the next boot. In either case, run LILO (as root) to update the boot sector.

Now you need to shut down some applications that were running on the desktop computer when the monitor died. The ones you want to kill gracefully are the ones with open data files, open temporary files, open sockets, etc. You usually can send shutdown notices to most apps with kill or killall. To see what processes are running, use something like COLUMNS=120 ps aux | less. You can narrow the list of processes to kill by grepping the output for a user name. On my desktop, I would type COLUMNS=120 ps aux | grep -i mylogin | less. (You may need to experiment with the column width.)

kill requires a process ID, which you will find in the second column of the ps output. killall takes the name of the application, e.g. netscape-navigator. With any luck, you can kill off any running apps gracefully and all the data will be preserved. If that doesn't work, add the option -9 to kill or killall. -9 is the ninja of kill signals: it will kill the app, but the application won't die gracefully. Data may not be saved, and temporary files may be left behind.

Next, you need to shut X down gracefully. Do that as part of the appropriate shutdown process that you have already determined. I use the following line, which also shuts down the SSH session:

shutdown -h now ; exit

Once you have done that, turn off power on the desktop. Now attach the new monitor. You will boot to a console. Log in as root and run Xconfigurator, a command-line utility that will write a new XF86Config with your video card and your new monitor. It will detect most new monitors and video cards for you. If it doesn't detect the video card or monitor correctly, you can select by hand.

To test your new X configuration, run startx. If you are really unlucky, you have a problem with your X configuration; you need to read up on configuring X, which is beyond the scope of this note. If that is successful, you may want to tweak your X configuration with xvidtune.

Once you are satisfied with the new X configuration, you may wish to restore booting to X by reversing the edit to /etc/inittab we made above. Or you may decide to be a bit conservative and leave your system booting to a console.

Try this with that high priced OS from Redmond!

Charles Curley (http://w3.trib.com/~ccurley/) is a freelance software engineer, writer and occasional cowpoke in the wilds of Wyoming.

Load Disqus comments