Ubuntu Server 18.04 – Dealing with misbehaving processes

How to Install MySQL 8.0 on Ubuntu 18.04

Regarding the ps command, by this point you know how to display processes running on your server, as well as how to narrow down the output by string or resource usage. But what can you actually do with that knowledge? As much as we hate to admit it, sometimes the processes our server runs fail or misbehave and you need to restart them. If a process refuses to close normally, you may need to kill that process. In this section, we introduce the kill and killall commands to serve that purpose.

The kill command accepts a PID as an option and attempts to close a process gracefully. In a typical workflow where you need to terminate a process that won’t do so on its own, you will first use the ps command to find the PID of the culprit. Then, knowing the PID, you can attempt to kill the process. For example, if PID 31258 needed to be killed, you could execute the following:

sudo kill 31258 

If all goes well, the process will end. You can restart it or investigate why it failed by perusing its logs.

To better understand what the kill command does, you first will need to understand the basics of Linux Signals. Signals are used by both administrators and developers and can be sent to a process either by the kernel, another process, or manually with a command. A signal instructs the process of a request or change, and in some cases, to completely terminate. An example of such a signal is SIGHUP, which tells processes that their controlling Terminal has exited. One situation in which this may occur is when you have a Terminal emulator open, with several processes inside it running. If you close the Terminal window (without stopping the processes you were running), they’ll be sent the SIGHUP signal, which basically tells them to quit (essentially, it means the shell quit or hung up).

Other examples include SIGINT (where an application is running in the foreground and is stopped by pressing Ctrl + C on the keyboard) and SIGTERM, which when sent to a process asks it to cleanly terminate. Yet another example is SIGKILL, which forces a process to terminate uncleanly. In addition to a name, each signal is also represented by a value, such as 15 for SIGTERM and 9 for SIGKILL. Going over each of the signals is beyond the scope of this chapter (the advanced topics of signals are mainly only useful for developers), but you can view more information about them by consulting the man page if you’re curious:

man 7 signal 

For the purposes of this section, the two types of signals we are most concerned about are SIGTERM(15) and SIGKILL(9). When we want to stop a process, we send one of these signals to it, and the kill command allows us to do just that. By default, the kill command sends signal 15 (SIGTERM), which tells the process to cleanly terminate. If successful, the process will free its memory and gracefully close. With our previous example kill command, we sent signal 15 to the process, since we didn’t clarify which signal to send.

Terminating a process with SIGKILL(9) is considered an extreme last resort. When you send signal 9 to a process, it’s the equivalent of ripping the carpet out from underneath it or blowing it up with a stick of dynamite. The process will be force-closed without giving it any time to react at all, so it’s one of those things you should avoid using unless you’ve literally tried absolutely everything you can think of. In theory, sending signal 9 can cause corrupted files, memory issues, or other shenanigans to occur. As for me, I’ve never actually run into long-term damage to software from using it, but theoretically it can happen, so you want to only use it in extreme cases. One case where such a signal may be necessary is regarding defunct (zombie) processes in a situation where they don’t close on their own. These processes are basically dead already and are typically waiting on their parent process to reap them. If the parent process never attempts to do so, they will remain on the process list. This in and of itself may not really be a big issue, since these processes aren’t technically doing anything. But if their presence is causing problems and you can’t kill them, you could try to send SIGKILL to the process. There should be no harm in killing a zombie process, but you would want to give them time to be reaped first.

To send signal 9 to a process, you would use the -9 option of the kill command. It should go without saying, though, to make sure you’re executing it against the proper process ID:

sudo kill -9 31258 

Just like that, the process will vanish without a trace. Anything it was writing to will be in limbo, and it will be removed from memory instantly. If, for some reason, the process still manages to stay running (which is extremely rare), you probably would need to reboot the server to get rid of it, which is something I’ve only seen in a few, very rare cases. If kill -9 doesn’t get rid of the process, nothing will.

Another method of killing a process is with the killall command, which is probably safer than the kill command (if for no other reason than there’s a smaller chance you’ll accidentally kill the wrong process). Like kill, killall allows you to send SIGTERM to a process, but unlike kill, you can do so by name. In addition, killall doesn’t just kill one process, it kills any process it finds with the name you’ve given it as an option. To use killall, you would simply execute killall along with the name of a process:

sudo killall myprocess 

Just like the kill command, you can also send signal 9 to the process as well:

sudo killall -9 myprocess 

Again, use that only when necessary. In practice, though, you probably won’t use killall -9 very often (if ever), because it’s rare for multiple processes under the same process name to become locked. If you need to send signal 9, stick to the kill command if you can.

The kill and killall commands can be incredibly useful in the situation of a stuck┬áprocess, but these are commands you would hope you don’t have to use very often. Stuck processes can occur in situations where applications encounter a situation from which they can’t recover, so if you constantly find yourself needing to kill processes, you may want to check for an update to the package responsible for the service or check your server for hardware issues.

Comments are closed.