SMBD's go into "D" (uninteruptable sleep) and never wake up

[Mike Rylander]

On Saturday 28 April 2001 12:35, you mumbled SMBD's go into "D" 
(uninteruptable sleep) and never wake up:
> I have s myriad of Samba 2.0.8 and 2.2.0+%U/%Dpatched servers. Two of
> the heaviest used ones are doing file serving for Win9x (and some WinNT
> WS and 2k Pro) clients. Very vanilla. Both are running Linux 2.4.3
> kernel, using NFS to connect to shared storage areas, FTP for remote
> access, and also running Netatalk to provide connectivity to Mac's.
>
> Both of these servers, on an increasingly frequent basis, are being
> subjected to what seems to be a heavy case of SMBD laziness, as the SMBD
> processes will go into the "D" state (uninteruptable sleep) and never
> come out. The user can log out and log back in (spawning a new SMBD) and
> continue on their merry way, but that process will never die unless I
> *gasp* reboot the server. It doesn't respond to any kill signals.
> Eventually, there gets to be so many that Samba refuses new logins
> outright (gracefully) and Netatalk just freezes the Macs (not like they
> aren't USED to freezing ;). They don't do this at the same time, and
> sometimes it'll be days before one of the starts this.

I had this problem a while back.  Running 2.0.7 as a simple workgroup server, 
I had a large amount of storage mounted via NFS and shared via Samba, and 
from time to time I would need to reboot the server to get rid of D-wait'd 
processes.  As soon as I moved the most heavily accessed shares (the [homes] 
shares) to one big box and shared them directly (as opposed to via NFS) every 
thing was fine.  As far as I can, this is a problem with state management in 
Linux's NFS driver.  One note, I did have greater success with two Solaris 
machines smb-sharing via NFS (of course, right?).  Hope this helps.

> Is this a known issue that I missed? Any feedback as to what would cause
> this permanent "D" state. I don't like it very much. If it responded to
> a kill, I'd be fine, but it just doesn't. I'd be happy to provide any
> information requested (within reason). Again, both 2.0.8 and 2.2.0 seem
> affected.

-- 
Mike Rylander
Senior Unix Administrator
Incanta, Inc.