Linux Process States

Linux Process States

While waiting for read() or write() to/from a file descriptor return, the process will be put in a special kind of sleep, known as "D" or "Disk Sleep". This is special, because the process can not be killed or interrupted while in such a state. A process waiting for a return from ioctl() would also be put to sleep in this manner.

An exception to this is when a file (such as a terminal or other character device) is opened in O_NONBLOCK mode, passed when its assumed that a device (such as a modem) will need time to initialize. However, you indicated block devices in your question. Also, I have never tried an ioctl() that is likely to block on a fd opened in non blocking mode (at least not knowingly).

How another process is chosen depends entirely on the scheduler you are using, as well as what other processes might have done to modify their weights within that scheduler.

Some user space programs under certain circumstances have been known to remain in this state forever, until rebooted. These are typically grouped in with other "zombies", but the term would not be correct as they are not technically defunct.

Linux Process State Code 'I'

ps queries procfs - /proc/[PID]/stat - for the process state. proc(5) says:

/proc/[pid]/stat

         Status information about the process.  This is used by ps(1).
It is defined in the kernel source file fs/proc/array.c.

And fs/proc/array.c says those tasks are idle.

Status of process on linux

First of all, there are more process states than "Running", "Done" and "Stopped", from man ps:

PROCESS STATE CODES
Here are the different values that the s, stat and state output
specifiers (header "STAT" or "S") will display to describe the
state of a process:

D uninterruptible sleep (usually IO)
R running or runnable (on run queue)
S interruptible sleep (waiting for an event to complete)
T stopped by job control signal
t stopped by debugger during the tracing
W paging (not valid since the 2.6.xx kernel)
X dead (should never be seen)
Z defunct ("zombie") process, terminated but not reaped by its parent

You can get the status of one process by its pid (process ID) using the command ps:

ps -q <pid> -o state --no-headers

From man ps:

-q pidlist
Select by PID (quick mode). This selects the processes whose
process ID numbers appear in pidlist. With this option ps reads the
necessary info only for the pids listed in the pidlist and doesn't
apply additional filtering rules. The order of pids is unsorted and
preserved. No additional selection options, sorting and forest type
listings are allowed in this mode. Identical to q and --quick-pid.

If you have the array of pid "All_Process_Pid" in your bash script, then you can just:

for i in "${All_Process_Pid[@]}"
do
echo "process $i has the state $(ps -q $i -o state --no-headers)"
done

What process states contribute to the load average of a server?

There is no standard way of calculating load average, it depends on the OS. Here's Linux's load calculator:

long calc_load_fold_active(struct rq *this_rq)
{
long nr_active, delta = 0;

nr_active = this_rq->nr_running;
nr_active += (long) this_rq->nr_uninterruptible;

if (nr_active != this_rq->calc_load_active) {
delta = nr_active - this_rq->calc_load_active;
this_rq->calc_load_active = nr_active;
}

return delta;
}

The processes Linux counts as active for the purpose of load averages are Running (R) and Uininterruptible (D).

Interruptible Sleep (S) is not counted, and neither is Defunct (Z) or Stopped (T).

Process state when calling syscall?

It's the process itself that switches to kernel mode and executes the system call - although it switches to a kernel stack to do so. A process executing inside the kernel has state Running, and can be pre-empted and end up in state Runnable.

How does the kernel know some process is on the state TASK_RUNNING(running) or TASK_RUNNING(ready)?

Linux has a macro current that denotes the task currently running in the CPU executing the kernel code. Here's a doc with more elaborate explanation.

how to figure out if process is really running or waiting to run on Linux?

The struct task_struct contains a long to represent current state:

volatile long state;          /* -1 unrunnable, 0 runnable, >0 stopped */

This simply indicates if a process is 'runnable'.

To see the currently executing process you should look at the runqueue. Specifically a struct rq (as defined in kernel/sched/sched.h) contains:

struct task_struct *curr, *idle, *stop;

The pointer *curr is the currently running process on this runqueue (there exists a runqueue per CPU).

You should consult files under kernel/sched/ to see how the Kernel determines which processes should be scheduled according to the different scheduling algorithms if you are interested in exactly how it arrives at the running state.



Related Topics



Leave a reply



Submit