Download (direct link):
telnet name_of_machine_with_no_operable_keyboard [login as a user] su
Now either execute ps axu |more, find the process id of the offending command in the ps output and do kill pid_of_offending_process or reboot your machine with:
/sbin/shutdown -rn now
This command will shutdown really fast, bypassing standard (longer) shutdown procedure--useful when the system becomes really buggy (the option -n will make "shutdown" kill all the processes before rebooting).
Please note that for security reasons, you cannot login to a remote machine as root (e.g., over the telnet). You have to login as a user and then execute su and give a password to become a super user (root).
The shutdown command may also be used to execute a shutdown later. E.g. (as root):
/sbin/shutdown -r 23:59
will reboot the system 1 minute before midnight. I could also use:
/sbin/shutdown -r +1
to shutdown 1 minute from now. I can cancel a scheduled shutdown with:
If the shutdown command is too long for you, you may want to try these two commands, which do exactly what their names suggest (as root):
A fancy way to shut down your computer is to switch your system to the runlevel 0 (for halt) or runlevel 6 (for reboot). Try it using (as root):
The meaning of the different runlevels is explained in the file /etc/inittab and here.
Part 3: Basic Operations FAQ
Linux Newbie Guide by Stan, Peter and Marie Klimas
3.1.6 How do I deal with a hanged program?
Buggy programs do hang under Linux. A crash of an application should not, however, affect the operating system itself so it should not be too often that you have to reboot your computer. Linux servers are known to run for more than a year without a reboot. In our experience, a misbehaving operating system may be a sign of hardware or configuration problems: we repeatedly encountered problems with the Pentium processor overheating (the fan on the Pentium did not turn as fast as it should or it stopped altogether, the heat sink on the Pentium was plugged with dirt), bad memory chips, different timing of different memory chips (you may try re-arranging the order of the chips, it might help), wrong BIOS setup (you should probably turn off all the "advanced" options, Linux takes care of things by itself). The "signal 11" error message is typically (99%) associated with hardware problems and is most likely to manifest itself when you perform computing-intensive tasks: Linux setup, kernel compilation, etc. If your Pentium has the tendency to overheat (very common for early Pentiums), here are some tips to keep it cool, particulary during hot weather: clean the processor heat sink, replace the processor fan, operate the computer with the cover off and aim an extra fan inside, increase the processor "wait-state" in the computer BIOS, don't overclock, decrease useless load, e.g., replace this super-fancy screen saver with a blank screen.
Not really hanged. Some programs might give the uninitiated impression of hanging, although in reality they just wait for user input. Typically, this happens if a program expects an input filename as a command line argument and no input filename is given by the user, so the program defaults to the standard input (which is console). For example, this command
may look like it's hanged but it waits for keyboard input. Try pressing <Ctrl>d (which means "end-of-file") to see that this will satisfy the cat command. Another example: I have seen many questions on the newsgroups about the "buggy" tar command that "hangs" when trying to uncompress a downloaded file, for example:
tar -zxv my_tar_file [wrong!]
This waits for user input too, since no option "-f filename" was specified so "my_tar_file" was not recognized as a filename. The correct command is:
tar -zxvf my_tar_filename
Please note that the filename must follow immediately after the option "f" (which stands for "filename). This WILL NOT work (very common mistake):
tar -zxfv my_tar_file [wrong!]
Any program (hanged or not) can be killed.
A text-mode program in the foreground can often be killed by pressing <Ctrl>c. This will not work for larger applications which block the <Ctrl>c, so it is not used on them accidentally. Still you can get back in control either by sending the program to the background by pressing <Ctrl>z (no guarantee this will work) or switching to a different terminal, for example using <Ctrl><Alt><F2> and login as the same user that hanged the program (this should always work). Once you are back in control, find the program you want to terminate, for example:
This command stands for "print status" and shows the list of programs that are currently being run by the current user. In the ps output, I find the process id (PID) of the program that hanged, and now I can kill it. For example:
will kill the program with the process id (PID) of "123".
As user, I can only kill the processes I own (this is, the ones which I started). The root can kill any process. To see the complete list of all processes running on the system issue: