BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
If you're responsible for a Linux system, you will occasionally have to manage Linux services. This means you must know how to start and stop services with the service command, and how to kill a service or process.
You may find that a Linux service or process becomes unresponsive -- running, but not working properly, and not quitting via the normal method. You may have to send a signal for the process to terminate.
There are different Linux signals that an administrator can send to a process via the kill command. The Linux kernel defines no less than 32 signals, of which SIGTERM, SIGHUP and SIGKILL are the most common.
Killing a process doesn't really mean that you kill it. So what is really happening when these signals are sent?
Basically, there are two ways that a Linux administrator can send commands to a process: from within the related program itself or from the kernel space. Always start from the related program. This is analogous to Microsoft Windows; before starting Task Manager to force quit a program, you first try to quit it by using the File > Quit menu option. Only if this path fails should you start using kill to send a signal to the process.
Kill it with kindness
Using the kill command to send the SIGTERM signal to the process is basically asking, "Dear process, please stop your activities." If this request comes from the kernel space, the process doesn't have the option to ignore it. In all cases, it will start to cease its activities.
In some situations, ceasing activities will take a while. Imagine shutting down a busy mail server that is handling dozens of active connections. You wait several minutes before the mail service is able to stop because you want it to disconnect all active connections decently.
Too often, administrators think the related service will cease activity seconds after issuing a kill command. And if it doesn't, they force it to do so by using the kill -9 command, which sends the SIGKILL signal to the process.
SIGKILL: Seek and destroy
Sending a SIGKILL signal doesn't politely ask the process to cease its activities -- it's more like putting a bullet in the head and ending it with gore. None of the files currently in use by the process will be closed properly. With SIGKILL, you risk damaging everything the process currently has in use.
Only send SIGKILL if you really have no other choice. In fact, assume that SIGKILL should never be sent to a process. In some situations, you may wait over 15 minutes for a process to shut down. Does that justify a SIGKILL signal? I don't think so. SIGKILL will harm the files that the process opens.
If possible, restart your entire system. By shutting down the system, all processes will receive a SIGTERM signal and will try to shut down nicely, where files are closed properly. Issuing a reboot may actually fix the problem and shut down the process that was preventing it from closing nicely. The result is that after this dependency was shut down, the refusing process will shut down as well, and in a few minutes your server will be up and running again, without damaging any files. Only use kill -9 as a very last resort.
About the author:
Sander van Vugt is an independent trainer and consultant based in the Netherlands. He is an expert in Linux high availability, virtualization and performance. He has authored many books on Linux topics, including Beginning the Linux Command Line, Beginning Ubuntu LTS Server Administration and Pro Ubuntu Server Administration.