0

What is the meaning of R / D from ps ax? Does it indicate a problem?

     3 ?        R    522:45 [ksoftirqd/0]
  4380 ?        Rl   1240:31 gdm-session-worker [pam/gdm-launch-environment]
  5938 ?        Rs     0:00 ps ax
  6148 ?        Rl   1405:54 gnome-shell --mode=gdm
Michael Mrozek
  • 93,103
  • 40
  • 240
  • 233
yael
  • 13,106

1 Answers1

3

In the ps manual, under the section "PROCESS STATE CODES":

   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

An R means that the process is in the run queue. It does not in any way indicate a problem.

A process in a D state will not handle signals straight away as it's currently stuck waiting for disk (usually, and this is where the letter D in the code comes from). This would indicate an issue if the process is stuck for a longer period of time or if multiple processes are in the same state. The problem is then probably related to high I/O load (too many processes wanting to read from a too slow disk, for example).

The additional character is also explained:

For BSD formats and when the stat keyword is used, additional characters may be displayed:

   <    high-priority (not nice to other users)
   N    low-priority (nice to other users)
   L    has pages locked into memory (for real-time and custom IO)
   s    is a session leader
   l    is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)
   +    is in the foreground process group

Related:

Kusalananda
  • 333,661
  • so what from the flags above is indicate about a problem , as I know - D is for sure – yael Mar 25 '19 at 18:07
  • @yael Waiting in uninterruptible sleep does not need to indicate a problem. If the process is stuck like that for long, or if multiple processes are stuck in the D state, then yes maybe. – Kusalananda Mar 25 '19 at 18:09
  • I not agree with you see please this case - https://access.redhat.com/solutions/41871 – yael Mar 25 '19 at 18:10
  • @yael The link you posted requires a login. Also, if you are certain, then why ask? The D state is a valid state to be in for a process while waiting for data to be delivered from e.g. disk. There's nothing inherently bad about it. Unless, as I said, it actually gets stuck there, which would indicate an inability of the resource that it's waiting on to deliver data fast enough. – Kusalananda Mar 25 '19 at 18:11
  • I update the question with redhat case please see the update – yael Mar 25 '19 at 18:13
  • @yael Yes, that goes in line with what I just said. Also, are you changing the question now? Are you instead asking about processes stuck in D state? – Kusalananda Mar 25 '19 at 18:15
  • ok I will change the question - – yael Mar 25 '19 at 18:16