|
UNIX Hints & Hacks |
 |
|||||||||||||||||||||
|
Chapter 2: Networking |
|
|||||||||||||||||||||
|
2.5 Shutdown, Halt, or Reboot over the Network
Bringing the system down over a network should be done only after all other attempts to resolve the problem have failed.
Some UNIX administrators argue that it should never be done at all. There are instances when it does become necessary to shut down or reboot the system. Whichever command you use, always make sure you are on the correct system and know the appropriate command to use (see section 1.17, "Bringing a System Down," in Chapter 1, "Topics in Administration") before executing any command that brings the system down.
As you know, issuing a halt command takes the system into a power-off state, whereas the shutdown command takes the system down and possibly places the system into a new init state, if needed. It is not wise to attempt this unless you have remote access to the console or the user is sitting at the system so you can talk her through the procedures.
Having access to a terminal server or a remote console is the next best thing to being there. Devices such as these on the market today enable you to take a system all the way down to the PROM level from the comfort of your own home. If you are interested in a terminal server, check-out the vendor/hardware/terminals section of the UNIX Guru Universe ( http://www.ugu.com) or go to an Internet search engine Web site and search with the keywords "terminal server."
There might come a time when the user is at another campus or across town. After a series of attempts at solving her problem, you are forced to shut down the system while you have her on the phone with you. This is okay, providing she does not hesitate to take advice from you. It often depends on the relationship you have with your user and her ability to move around in UNIX . If you are able to guide your user through a series of steps without frustrating her by the process, proceed. Otherwise, assure her that you are heading straight over to take care of the problem.
Using reboot over the network should still be attempted only when all else fails. It is always best to have a person at the terminal, if possible, when you initiate the reboot command. As the command is executed, your connection to the remote host is terminated and you need the user to be your eyes and describe what is taking place on the terminal. You are able to tell the state of the system as she reads the output of the boot process to you, and determine whether the reboot is successful or not.
Many circumstances warrant an administrator to force a reboot remotely over the network. If the hardware appears to be okay and there's nothing wrong with the kernel, you are still taking a risk, but the system more than likely will reboot successfully, without any problems.
The nice thing about having a person in front of the terminal is having her read the boot-up process line-by-line. In working with your systems day in and day out, you learn step-by-step what you should and shouldn't see on the screen as it boots up.
On some large servers with databases and special applications, the shutdown process can take up to 10 to 15 minutes before the system completes its graceful shutdown. This is sometimes enough to get across campus or to another building where the server is waiting in a halted state. You can tell the user that it saves time to do it remotely; not to mention that if the system isn't down by the time you get there and is hung, something even more serious could be the problem.
The reality is that in most cases a reboot is executed because the graphics, an application, or the desktop are hung and you cannot kill the running process. There are times when processes go into a zombie state and you know nothing is wrong with the system, but just these processes. Likewise, NFS mount points could go stale; when they do, the only recourse, if they do not unmount or remount, is to reboot. In almost every case I try to verify that the user or computer operator is in the area or in front of the terminal.
Man pages:
halt, reboot, shutdown
|
UNIX Hints & Hacks |
|
|||||||||||||||||||||
|
Chapter 2: Networking |
|
|||||||||||||||||||||
|
© Copyright Macmillan USA. All rights reserved.
