43

I'm using "Linux hostname 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux"

All the client machines will use Thin-client ,I will use my laptop for working and I will mount my home directory from server to my laptop.

If I open the firefox in my laptop the firefox window will not open because the process is in 'D' state, and all other users machines got hang up and the lockd process is in 'D' state,

ps ajx | grep firefox

1  6187  4313  4313 ?   -1 D<    1030   3:16 /usr/lib/firefox-3.5b4pre/firefox-3.5

   7610  7622  7621  7610 pts/3      7621 S+    1030   0:00 grep firefox

if I check the syslog

Jul 13 10:35:56 hostname kernel: [222583.872059] lockd: cannot monitor laptop

Jul 13 10:35:57 hostname kernel: [222583.872059] lockd: cannot monitor laptop

ps ajx | grep lockd

root 9178 0.0 0.0 0 0 ? D< 13:35 0:00 [lockd]

root 11039 0.0 0.0 3340 796 pts/3 S<+ 14:18 0:00 grep lockd

The same message for all the client machines.

When a process will goes to 'D' state?

When the lockd process will go to 'D' state?

What is the purpose of lockd process.

Gilles 'SO- stop being evil'
  • 829,060
ungalnanban
  • 541

3 Answers3

40

It means "uninterruptible sleep".

D    Uninterruptible sleep (usually IO)

In this state, a process doesn't wake up right away to process signals. When doing device I/O it's the only way to go (otherwise data corruption could result).

Community
  • 1
34

D state code means that process is in uninterruptible sleep.

  • usually this is due to I/O.
  • lockd is in-kernel daemon that manages NFS locking.

Probably, your problem has to do with NFS communication.

Semnodime
  • 347
  • 1
    how to avoid this ? the lockd process should not go to 'D' state, what I need to do ? – ungalnanban Jul 16 '11 at 07:48
  • @ungalnanban: It is impossible, processes always go in and out of 'D' if using I/O. So in your case process is trying to, for example, read or write some data, acquire a lock, cannot do that and keeps waiting. You have to debug what it is waiting for etc. I am not an NFS expert to tell that, sorry. –  Jul 16 '11 at 16:45
0

Despite what the other answers say, D state doesn't necessarily mean that a task is uninterruptible. For example, many D state processes will, in fact, exit on terminal signals. You can read some examples of using that for testing in this article.

In Linux, many D states are entered with the TASK_KILLABLE flag set:

linux % git grep -ihc _killable | paste -sd+ | bc
539

TASK_KILLABLE was created because -- while in some cases we do actually need to shield the process from any signal interaction at all -- in some cases it's fine as long as we know the process will terminate with no more userspace instructions executed. For example, in D states where DMA is not being performed (for example, vfork()), we have to block in order to prevent some unsafe operating condition, but there's no reason for us to continue to wait if the next thing we're going to do is simply terminate – it's a waste of time and of a process.

Instead of being fully uninterruptible, with TASK_KILLABLE, when we receive a signal we check if the signal is fatal (that is, it's either a non-trappable fatal signal, or the program has no userspace handler for a signal with a default terminal disposition), and if it is, we terminate the process without allowing it to execute any more userspace instructions.

All a D state process represents is a process which cannot execute any more userspace instructions, but blocking all signals is only one interpretation of how to achieve that, and it's not necessary in all circumstances.

Chris Down
  • 125,559
  • 25
  • 270
  • 266