Process States¶

The STAT column shows what a process is doing right now: running, sleeping, blocked in the kernel, stopped or exited. The states matter in troubleshooting because two of them, D and Z, ignore kill -9, and D inflates the load average without using CPU.

Track: Core · Interview weight: High

Must-Know Facts¶

Seeing Every State¶

One of each: a busy loop (R), sleep (S), a stopped job (T) and a Python parent with an unreaped child (Z).

( while :; do :; done ) >/dev/null 2>&1 &
sleep 300 >/dev/null 2>&1 &
sleep 300 >/dev/null 2>&1 &
kill -STOP $!
python3 zombie.py >/dev/null 2>&1 &
ps -o pid,stat,wchan:20,comm -p 1975,1976,1977,1978 --ppid 1978

Output:

    PID STAT WCHAN                COMMAND
   1975 R    -                    bash
   1976 S    hrtimer_nanosleep    sleep
   1977 T    do_signal_stop       bash
   1978 S    hrtimer_nanosleep    python3
   1980 Z    -                    python3

1977 still shows bash because it was stopped before it could exec sleep: the child of & is a copy of the shell until execve() runs. Kernel threads add the I state:

ps -eo stat,comm | awk '$1 ~ /^I/' | head -3
ps -eo stat= | cut -c1 | sort | uniq -c

Output:

I<   rcu_gp
I<   rcu_par_gp
I<   slub_flushwq
     66 I
      2 R
     54 S
      1 T
      1 Z

The two R tasks are the busy loop and ps itself.

stateDiagram-v2
    [*] --> R: fork()
    R --> S: wait for event
    S --> R: event or signal
    R --> D: wait inside kernel (I/O, lock)
    D --> R: kernel call returns
    R --> T: SIGSTOP / SIGTSTP
    T --> R: SIGCONT
    R --> Z: exit()
    Z --> [*]: parent wait()

Interruptible vs Uninterruptible Sleep¶

A process in S sleeps until an event arrives or a signal interrupts the system call. A process in D sleeps where the kernel cannot safely abandon the operation, such as waiting for a block device, a hung NFS server or a frozen filesystem, so pending signals are delivered only after the call returns.

Freezing a filesystem with fsfreeze reproduces a D state on demand (as root):

truncate -s 200M /var/tmp/frz.img
mkfs.ext4 -q /var/tmp/frz.img
mkdir -p /mnt/frz
mount -o loop /var/tmp/frz.img /mnt/frz
fsfreeze -f /mnt/frz
( echo data > /mnt/frz/f ) >/dev/null 2>&1 &
ps -eo pid,stat,wchan:32,comm | awk '$2 ~ /^D/'
cat /proc/2000/stack
grep State /proc/2000/status

Output:

   2000 D    percpu_rwsem_wait                bash
[<0>] percpu_rwsem_wait+0x118/0x140
[<0>] mnt_want_write+0x98/0xc0
[<0>] open_last_lookups+0x2cb/0x3b0
[<0>] path_openat+0x8d/0x290
[<0>] do_filp_open+0xb2/0x160
[<0>] do_sys_openat2+0x9f/0x160
[<0>] __x64_sys_openat+0x55/0x90
[<0>] x64_sys_call+0xdac/0x1fd0
[<0>] do_syscall_64+0x35/0x80
[<0>] entry_SYSCALL_64_after_hwframe+0x6e/0xd8
State:  D (disk sleep)

The stack reads bottom to top: an openat() system call wants write access to the mount (mnt_want_write) and waits on the freeze lock. SIGKILL does not remove it; thawing does.

In an interactive root shell the same freeze shows what kill -9 does to a D job:

fsfreeze -f /mnt/frz
echo x > /mnt/frz/g &
kill -9 %1
jobs -l
fsfreeze -u /mnt/frz
jobs -l

Output:

[1] 6083
[1]+  6083 Running                 echo x > /mnt/frz/g &
[1]+  6083 Killed                  echo x > /mnt/frz/g

The job stayed Running after kill -9 and was reported Killed only after the thaw: the pending SIGKILL took effect as soon as the kernel call returned.

D State and the Load Average¶

Linux load average counts tasks in R and D. Four tasks blocked on the frozen filesystem for about two minutes raised the 1-minute load to 3.46 while the CPUs were idle.

cat /proc/loadavg
top -b -n 1 | head -3
vmstat 1 2 | tail -2

Output:

3.46 1.40 0.61 1/137 5927
top - 19:18:25 up 23 min,  0 user,  load average: 3.46, 1.40, 0.61
Tasks: 127 total,   1 running, 126 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st 
 0  0      0 7586424  21524 337688    0    0   157   115  253    0  4  0 96  0  0  0
 0  0      0 7586424  21524 337728    0    0     0     0   63   59  0  0 100  0  0  0

top counts D tasks as sleeping, and wa stays at 0 because no device I/O is pending: the tasks wait on a lock, not on a disk. On a server with a hung NFS mount or a failing disk the same pattern appears, usually with wa and vmstat's b column raised.

Stopped Processes¶

SIGSTOP (not catchable) and SIGTSTP (Ctrl-Z, catchable) stop a process; SIGCONT resumes it. A process stopped for too long looks hung to its clients, because its sockets stay open but nothing reads them.

sleep 100 >/dev/null 2>&1 &
sleep 0.3
kill -STOP $!; sleep 0.5
kill -TERM $!; sleep 0.5
ps -o pid,stat,comm -p $!
grep ShdPnd /proc/$!/status
kill -CONT $!; sleep 0.5
ps -o pid,stat,comm -p $! || echo "terminated after SIGCONT"

Output:

    PID STAT COMMAND
   2526 T    sleep
ShdPnd: 0000000000004000
    PID STAT COMMAND
terminated after SIGCONT

SIGTERM (bit 15, 0x4000) stayed pending while the process was stopped and took effect after SIGCONT. SIGKILL is the exception: it ends a stopped process at once.

STAT Flags¶

Ssl is a typical daemon (sleeping, session leader, threaded); R+ is a command running in the foreground of a terminal.

Common Errors¶

[1]+ 6083 Killed echo x > /mnt/frz/g¶

Cause: the shell reports a job ended by SIGKILL; for a D process the report appears only when the blocking call returns, not when kill -9 was sent.

Fix: if kill -9 seems to do nothing, check STAT for D and fix the resource in wchan.

Interview Checkpoints¶

Related¶

• Process Lifecycle: zombies and reaping
• Signals: stop, continue and pending signals
• Viewing Processes: ps and top columns
• Process Won't Die: D, Z and restarting services as an interview drill

Captured on Rocky Linux 10.2 (iximiuz Labs microVM, kernel 6.1.167), 2026-09.