On every Linux operating system instance, there are processes that run. These can include ssh processes, sshd, and cron jobs. Any application that needs to be run invokes a process. Often, those processes create other processes. For that reason, there is a hierarchy of processes. An example of this is when you login, your shell is a process. It is created by a parent process.

We won't go into too much detail about parent processes, but when you run new applications or processes, the parent process of those is your shell process. When you log out, all of those child processes get cleaned up as part of that log out.

When introduced to the concept of processes, it is expected that these processes would be running 100% of the time. A process that is running consumes CPU so if all of the processes were always running, CPU usage would be very high and it would be difficult to run many processes at the same time. For this reason there are various states, some consume CPU, while others do not or if they do, very minimally.

What are the 5 Linux Process States?

There are five Linux process states. They are as follows: running & runnable, interruptable_sleep, uninterruptable_sleep, stopped, and zombie. Each of these process states exist for a very well defined reason. Understanding these states can be very helpful when troubleshooting issues like resource exhaustion or out of control process generation. That understanding is even more important when we need to understand how to terminate or kill the processes as depending on the process state, it may require a different technique.

How to Find the Process State

The most simple way to find the process state is to use the top command. This command lists the top processes running — and a few columns by default. The state is usually reflected as one character in the "S" column. The ps command can be used as well. This will list processes based on the criteria you pass it with flags. It accepts a few different flags depending on the information you want to look at. The common one is "ps aux"

As always, refer to the man page for your distribution and specific command but the most common mappings of character to state are as follows.

• 'D' = UNINTERRUPTABLE_SLEEP

• 'R' = RUNNING & RUNNABLE

• 'S' = INTERRRUPTABLE_SLEEP

• 'T' = STOPPED

• 'Z' = ZOMBIE

RUNNING & RUNNABLE Process State

While running and runnable are usually lumped together, there are minor differences between them. Most of the time that distinction does not matter because it indicates the process is either queued up to run or in the process of running. As the name implies, running is actively running and allocated to a CPU/CPU core or thread. This will affect CPU utilization metrics in terms of real-time usage.

The distinction between running and runnable is that a runnable process is ready and lined up to be run, but for whatever reason, the CPU is not ready for it to be scheduled. Therefore it is queued up to be running. In a virtual machine environment this is more common as physical CPUs are over-provisioned so virtual CPUs may have a little more latency or CPU ready. This can happen in the physical world too when there are just too many processes scheduled to run and not enough CPU time available.

INTERRRUPTABLE_SLEEP Process State

During the course of a process running, it will get to a point where it is waiting on data. This may be in the form of input from the terminal such as asking the user for input. In other cases the process may be a web server and it is idling, waiting for a query.

While it waits for this, a well coded application goes into the INTERRUPTABLE_SLEEP state. In this state, a process can easily be terminated without issue. Going into this process state while waiting for input allows the process to take a back seat and give other processes CPU time. It would be a waste of CPU to cycle through CPU time unnecessarily.

UNINTERRUPTABLE_SLEEP Process State

Like INTERRUPTABLE_SLEEP, UNINTERRUPTABLE_SLEEP is a state where the process is waiting on something. Typically in this state, interrupting could cause some major issues. It is rare to catch a process in this state but when it is, it is usually due to a system call or syscall. A great example is the mkdir command. It makes a syscall to the kernel and during that enters this state. For local disks, this is instantaneous except in extreme circumstances. With a networked file system like NFS, it’s possible that this could hang indefinitely in this state given the right conditions.

For example if the network disconnected while this was being run at the right time, it could hang in this state, waiting for the network to return. Other examples of being in this state for a prolonged period of time are usually due to kernel driver bugs.

How to Kill the Sleeping Process?

Whether you can kill a sleeping process or not highly depends on whether it is interruptible or uninterruptible. Usually an interruptible sleep state can be killed with the kill command or "kill -9" if you want it to happen immediately. On the other hand the uninterruptible sleep state cannot be killed. You can issue a kill to it but that kill will be queued up until it gets out of this state. Alternatively rebooting the system is an option.

Processes stuck in UNINTERRUPTABLE_SLEEP are typically edge cases in unexpected states. Whether that is a network requirement that drops off the map or a buggy kernel driver, these are states that can become very inconsistent if killed and therefore not allowed.

STOPPED Process State

The STOPPED process you might think of it more as a suspended process. Many applications  and console tools/applications allow you to use Control + Z to suspend processes. In this state, the process is put on hold and not responsive. An example of when you might have a process in this state is when you have a foreground application requesting user input, but you are not ready to input that yet. You may Control+Z it and move on to something else. When you are ready to return to it you can run the "fg" command to bring it back.

ZOMBIE Process State

Processes in ZOMBIE state may sound like a strange state to be in. In basic terms, this is an interim state after a process exits — but before its parent removes it from the process table. When a process terminates it is the responsibility of the parent to "reap" the child process and cleanup the process table.

Typically, you only run into zombie processes when the parent has not done this cleanup and you have a process that is lingering. The name likely comes from the analogy that zombies are not dead, they're undead so you can't kill them! Think of a process in this state along those lines. It has already terminated but it is not quite dead yet. The analogy doesn't fully fit but it is likely where the name came from.

How to Kill the ZOMBIE Process?

We said you cannot kill a zombie process, but how do you really kill it? As we referenced, the parent process is responsible for reaping it and you can trigger a parent to do this.

The first step is to find its parent process. Typically there is a column in the "ps" output for PPID or Parent Process ID. You want to identify this number. Once you do you can send a SIGCHLD signal to that parent to tell it to perform this cleanup.

kill -s SIGCHLD <PPID>

In worst case scenarios where the parent is generating a lot of zombie processes that are not getting cleaned up, you can kill or restart the parent. However, this should be used sparingly if you are sure this is what you want to do. It can have unintended consequences. The blessing and the curse of Linux is that there’s always more to learn. Whether you’re aiming for a certification or just an understanding of the technology, consider taking a CBT Nuggets course in Linux.