Understanding Uninterruptible Sleep States In Linux

In Linux, an uninterruptible sleep state is a process that is blocked from performing a system call and cannot be interrupted or killed until the system call completes. This is usually due to the process waiting on I/O (such as disk operations) or a hardware problem, where the device driver is waiting for the hardware to perform an action that will never occur. In rare cases, the process can get stuck in this state, requiring a system reboot. Linux processes can be put into either interruptible or uninterruptible sleep states, with the latter requiring an explicit wake-up call to resume.

Uninterruptible sleep is a state that a process can enter when doing certain system calls

However, in rare cases, the process can get stuck in the uninterruptible sleep state, often due to buggy kernel drivers or other issues. When this happens, the only recourse is often to reboot the system, as there is no way to kill the process. This is similar to the zombie process state, where a process cannot be killed, but the causes for the two states are different.

Linux has two ways of putting running processes to sleep: interruptible sleep (S) and uninterruptible sleep (D). In both cases, the process is waiting for an event to complete. In the case of interruptible sleep, the process can return to the running state through an explicit wake-up call or by receiving a signal. However, in uninterruptible sleep, the process ignores signals, and the only way to return to the running state is through an explicit wake-up call.

The uninterruptible sleep state is relevant when a process is in a system call (kernel function) that cannot be interrupted by a signal. For example, the read() system call can take a long time, and during this time, the process is sleeping and blocking on the hardware. While it is sleeping, the process can receive a Unix asynchronous signal, causing the system call to exit prematurely and return to user space. However, if the process is in the uninterruptible sleep state, it cannot be interrupted by a signal.

There is a recent type of state known as "killable" that is based on the uninterruptible state but accepts fatal signals that will interrupt the sleep state. This state is useful when writing custom code, as it provides a compromise between the interruptible and uninterruptible sleep states.

Processes in the TASK_UNINTERRUPTIBLE state ignore signals

Linux has two ways of putting running processes to sleep: interruptible sleep (S) and uninterruptible sleep (D). In both cases, the process is waiting for an event to complete. However, there is a key difference between the two. A process in the interruptible sleep state can return to the running state either by using an explicit wake-up call or by receiving a signal. On the other hand, a process in the uninterruptible sleep state is ignoring signals. This means that the only way to transition from uninterruptible sleep to the running state is with an explicit wake-up call.

Processes in the TASK_UNINTERRUPTIBLE state are in kernel mode and do not accept interruption signals. They are waiting for a specific event to occur and will only be woken up by that event. This is in contrast to processes in the TASK_INTERRUPTIBLE state, which can be woken up by signals and are expecting a possible signal.

The reason that processes in kernel mode cannot be interrupted by signals is that doing so could potentially corrupt the kernel's data structures. This is because the process cannot be killed in kernel mode, as it could corrupt the kernel structures used by other processes in the same machine. Therefore, the process must wait until it returns to user mode before it can be interrupted or killed.

The uninterruptible sleep state is typically entered when performing certain system calls that cannot be interrupted by signals. In rare cases, due to buggy kernel drivers or other issues, a process can get stuck in the uninterruptible sleep state. When this happens, the only recourse is often to reboot the system, as there is no way to kill the process.

To prevent processes from getting stuck in the uninterruptible sleep state, it is important to identify and manage them effectively. One way to do this is to use the TASK_KILLABLE state, which is a compromise between interruptible and uninterruptible sleep. In this state, the process can still be interrupted by fatal signals, allowing it to be killed if necessary.

Uninterruptible sleep is usually a result of waiting on I/O

In Linux, a process can be put into interruptible sleep or uninterruptible sleep. In the case of uninterruptible sleep, the process is waiting for an event to complete, and it is ignoring signals. This is denoted by the letter 'D'.

For example, certain local I/O operations, such as the mkdir(2) system call, are not interruptible. If this operation gets stuck, the program can enter the uninterruptible sleep state, and the only recourse is to reboot the system.

To avoid issues with uninterruptible sleep, it is important to keep system drivers up to date and check release notes. From a development perspective, reducing the number of uninterruptible system calls used in code can help minimize the chances of a process getting stuck in uninterruptible sleep.

It is worth noting that most system calls that are uninterruptible happen instantaneously, so processes in the uninterruptible sleep state are rarely observed. However, when a process does get stuck in this state, it can cause significant issues, as it cannot be killed and may require a system reboot to resolve.

Uninterruptible sleep can be caused by buggy kernel drivers

Uninterruptible sleep is a state that a process can enter when making certain system calls. In this state, the process is blocked from performing a system call, and it cannot be interrupted (or killed) until the system call is complete. While most of these uninterruptible system calls are effectively instantaneous, in rare cases, the process can get stuck in the uninterruptible state. This can be caused by buggy kernel drivers, but there may be other reasons as well.

When a process is in the uninterruptible sleep state, it is not sensitive to user signals and cannot be interrupted or killed by the user. The only way for the process to return to the running state is through an explicit wake-up call. This is in contrast to interruptible processes, which can be interrupted by signals and can return to the running state through either an explicit wake-up call or by receiving a signal.

The uninterruptible sleep state has some advantages over the interruptible sleep state. Programming system calls for interruptible sleep is more complex as it requires extensive code in both kernel mode and user mode. On the other hand, uninterruptible sleep makes handling system calls smoother and is often used for short processes or to generate atomic calls.

However, when a process gets stuck in the uninterruptible sleep state, it can cause significant issues. In some cases, the only way to resolve the problem is to reboot the system. This is because there is no way to kill the process, and it can bring down the entire system if not addressed.

Buggy kernel drivers can cause a process to get stuck in the uninterruptible sleep state. This can occur due to various reasons, such as hardware problems, device driver issues, or network-related challenges. For example, certain local I/O operations, such as the mkdir(2) system call, are not interruptible and can result in a program getting stuck in the uninterruptible sleep state. Additionally, issues with NFS servers or unreliable NFS appliances can lead to processes entering uninterruptible sleep during I/O operations, impacting the functionality of the system.

The killable state is based on the uninterruptible state but accepts FATAL signals

Linux has two ways of putting running processes to sleep: interruptible sleep (S) and uninterruptible sleep (D). When a process is in uninterruptible sleep, it is in a system call (kernel function) that cannot be interrupted by a signal. This means that the process cannot be killed until it gets out of the D state.

The killable state, also known as TASK_KILLABLE, is a recent type of state that serves as a compromise between interruptible sleep and uninterruptible sleep. It is based on the uninterruptible state but accepts FATAL signals that will interrupt the sleep state. This means that if the call gets stuck, it can be killed.

The killable state was introduced to address cases where a process gets stuck in the uninterruptible sleep state. In such cases, the only way to terminate the process is to reboot the system. With the killable state, a process in the D state will check if the signal it receives is fatal. If it is, the process will be terminated without allowing it to execute any more userspace instructions.

It is important to note that not all system calls implement the killable state. For those that don't, processes still rely on uninterruptible sleep. Additionally, the killable state does not survive a SIGKILL signal, as it is always deadly and cannot be caught in userspace.

Frequently asked questions