samba - Jul 2006 - tdb/tdbutil.c:tdb_chainlock_with_timeout_internal

Hello. I run samba 3.0.21c on RHEL AS 4 EMT_64 U3 and I've experienced a
strange problem where smbd will go (and stay) in the D state.  While
waiting for IO (possibly), these smbd processes do not respond to client
requests, thus samba appears to be down.  I could not kill these
processes via kill -9 , so I rebooted which worked.

 

The only error I could see out of the ordinary would be (from a smb
client entry on the server under ./samba/var).

 

tdb/tdbutil.c:tdb_chainlock_with_timeout_internal

 

I am not giving much to go on, but I can give more information if you
think this error has some link to my problem.  Should I upgrade to the
latest stable and does it address this error?

 

I will say that ./samba/private is shared between two identical samba
servers running smbd simultaneously.  By shared, I mean that the
./private directory is on a shared filesystem (via Veritas clustered
filesystem).  Each server is running its own independent binaries and
./var/locks. But only one server is running nmbd at time.  The other one
is always ready to start nmbd upon nmbd failure.

 

If secrets.tdb is shared, would this really only be involved with
nmbd/smbd during domain membership .  BTW - These samba servers are
domain members only. 

 

 

Thanks,

Bill Pappas - System Integration Engineer - SAN 

St. Jude Children's Research Hospital

332 North Lauderdale

Memphis, TN 38105

Danny Thomas Tower - Room D1010

Mail Stop 312

On Fri, Jul 21, 2006 at 04:59:51PM -0500, Pappas, Bill
wrote:
> Hello. I run samba 3.0.21c on RHEL AS 4 EMT_64 U3 and I've experienced
a
> strange problem where smbd will go (and stay) in the D state.  While
> waiting for IO (possibly), these smbd processes do not respond to client
> requests, thus samba appears to be down.  I could not kill these
> processes via kill -9 , so I rebooted which worked.
> I am not giving much to go on, but I can give more information if you
> think this error has some link to my problem.  Should I upgrade to the
> latest stable and does it address this error?
Try 3.0.23a, due out today but I doubt it will help you. smbd only
gets stuck in the D wait state when the kernel doesn't get back to
it. That shouldn't happen on an fcntl call which is a "slow"
system
call that should be able to be interrupted by a signal. I'm guessing
the Veritas filesystem isn't doing this right.
> I will say that ./samba/private is shared between two identical samba
> servers running smbd simultaneously.  By shared, I mean that the
> ./private directory is on a shared filesystem (via Veritas clustered
> filesystem).  Each server is running its own independent binaries and
> ./var/locks. But only one server is running nmbd at time.  The other one
> is always ready to start nmbd upon nmbd failure.
That's almost certainly your problem. The Veritas clustered filesystem
is getting the smbd stuck. Why are you doing this (share the tdb directory).
It won't work.

Jeremy.

I will say this works for weeks on end w/o a problem.  When you say this will
not work, why? I've had no real problems with the veritas clustered fs.  It
adheres to file locking and fcntl operations like any normal local filesystem
(ext3).

What problems would arise from sharing secrets.tdb? Again, I never have nmbd
running on both servers. I do not share any .tdb files under ./var/locks.

--------------------------


-----Original Message-----
From: Jeremy Allison <jra@samba.org>
To: Pappas, Bill <Bill.Pappas@STJUDE.ORG>
CC: samba@lists.samba.org <samba@lists.samba.org>
Sent: Fri Jul 21 17:36:29 2006
Subject: Re: [Samba] tdb/tdbutil.c:tdb_chainlock_with_timeout_internal

On Fri, Jul 21, 2006 at 04:59:51PM -0500, Pappas, Bill
wrote:
> Hello. I run samba 3.0.21c on RHEL AS 4 EMT_64 U3 and I've experienced
a
> strange problem where smbd will go (and stay) in the D state.  While
> waiting for IO (possibly), these smbd processes do not respond to client
> requests, thus samba appears to be down.  I could not kill these
> processes via kill -9 , so I rebooted which worked.
> I am not giving much to go on, but I can give more information if you
> think this error has some link to my problem.  Should I upgrade to the
> latest stable and does it address this error?
Try 3.0.23a, due out today but I doubt it will help you. smbd only
gets stuck in the D wait state when the kernel doesn't get back to
it. That shouldn't happen on an fcntl call which is a "slow"
system
call that should be able to be interrupted by a signal. I'm guessing
the Veritas filesystem isn't doing this right.
> I will say that ./samba/private is shared between two identical samba
> servers running smbd simultaneously.  By shared, I mean that the
> ./private directory is on a shared filesystem (via Veritas clustered
> filesystem).  Each server is running its own independent binaries and
> ./var/locks. But only one server is running nmbd at time.  The other one
> is always ready to start nmbd upon nmbd failure.
That's almost certainly your problem. The Veritas clustered filesystem
is getting the smbd stuck. Why are you doing this (share the tdb directory).
It won't work.

Jeremy.

On Fri, Jul 21, 2006 at 04:59:51PM -0500, Pappas, Bill
wrote:
> Hello. I run samba 3.0.21c on RHEL AS 4 EMT_64 U3 and I've experienced
a
> strange problem where smbd will go (and stay) in the D state.  While
> waiting for IO (possibly), these smbd processes do not respond to client
> requests, thus samba appears to be down.  I could not kill these
> processes via kill -9 , so I rebooted which worked.
You need to find out in which system call the processes are
stuck. If it turns out to be the fcntl call on the
secrets.tdb, then Jeremy is right that it is a Veritas bug.
If they are stuck somewhere else then we need to look
further.

strace -p <pid> 

on such a process might show you the syscall where it hangs.

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.samba.org/archive/samba/attachments/20060722/03124b94/attachment.bin

Jeremy Allison wrote:
>>Then it might be an intermittent bug in Veritas. What system call is
>>smbd hanging on ? smbd should never hang in the D wait state unless
>>it's a filesystem bug.
I am beginning to believe that this could make sense. Let me emphasize
that ./private/secrets.tdb is shared between two samba servers (via
clustered vxfs) that are running independently.  Only one server runs
nmbd at a time as veritas cluster server fails nmbd over between servers
as needed.  I just figured keeping smbd running up on both servers to
reduce failover time.  I discovered that I had to share secrets.tdb to
ensure that either samba server would remain as a domain member server.
Is there another way to do what I am doing?  I'd gladly stop sharing
this file if I could keep smbd up on both servers.  Does smbd need a
lock on secrets.tdb? I thought (probably wrong) that only nmbd relied on
this file?

Further below, you will find some more logs between clients and the
server running nmbd and smbd (as the other was sitting idle with smbd
running). SJMEMDC05 is a windows domain controller and the other clients
are windows explorer clients. 

When you see these logs, they appear to confirm that secrets.tcb is
directly involved, but how would a locking issue with this file cause
smbd to go to the D state (and stay)?

log.hc-dfinkletest:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
tdb_lock failed on list 78 ltype=1 (Interrupted system call)
log.hc-dfinkletest:  tdb_chainlock_with_timeout_internal: alarm (10)
timed out for key SJMEMDC05 in tdb
/usr/local/samba-3.0.21c/private/secrets
.tdb
log.hc-dfinkletest:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
tdb_lock failed on list 78 ltype=1 (Interrupted system call)
log.hc-dfinkletest:  tdb_chainlock_with_timeout_internal: alarm (10)
timed out for key SJMEMDC05 in tdb
/usr/local/samba-3.0.21c/private/secrets
.tdb
log.hc-dfinkletest:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
tdb_lock failed on list 78 ltype=1 (Interrupted system call)
log.hc-dfinkletest:  tdb_chainlock_with_timeout_internal: alarm (10)
timed out for key SJMEMDC05 in tdb
/usr/local/samba-3.0.21c/private/secrets
.tdb
log.hc-mwang1:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
tdb_lock failed on list 78 ltype=1 (Interrupted system call)
log.hc-mwang1:  tdb_chainlock_with_timeout_internal: alarm (10) timed
out for key SJMEMDC05 in tdb
/usr/local/samba-3.0.21c/private/secrets.tdb
log.hc-mwang1:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
tdb_lock failed on list 78 ltype=1 (Interrupted system call)
log.hc-mwang1:  tdb_chainlock_with_timeout_internal: alarm (10) timed
out for key SJMEMDC05 in tdb
/usr/local/samba-3.0.21c/private/secrets.tdb
log.hc-mwang1:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
tdb_lock failed on list 78 ltype=1 (Interrupted system call)
log.hc-mwang1:  tdb_chainlock_with_timeout_internal: alarm (10) timed
out for key SJMEMDC05 in tdb
/usr/local/samba-3.0.21c/private/secrets.tdb
log.hc-mwang1:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
tdb_lock failed on list 78 ltype=1 (Interrupted system call)
log.hc-mwang1:  tdb_chainlock_with_timeout_internal: alarm (10) timed
out for key SJMEMDC05 in tdb
/usr/local/samba-3.0.21c/private/secrets.tdb
log.hc-mwang1:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
tdb_lock failed on list 78 ltype=1 (Interrupted system call)
log.hc-mwang1:  tdb_chainlock_with_timeout_internal: alarm (10) timed
out for key SJMEMDC05 in tdb
/usr/local/samba-3.0.21c/private/secrets.tdb
log.hc-mwang1:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
tdb_lock failed on list 78 ltype=1 (Interrupted system call)
log.hc-mwang1:  tdb_chainlock_with_timeout_internal: alarm (10) timed
out for key SJMEMDC05 in tdb
/usr/local/samba-3.0.21c/private/secrets.tdb

Thanks,
Bill Pappas - System Integration Engineer - SAN 
St. Jude Children's Research Hospital
332 North Lauderdale
Memphis, TN 38105
Danny Thomas Tower - Room D1010
Mail Stop 312

-----Original Message-----
From: Jeremy Allison [mailto:jra@samba.org] 
Sent: Saturday, July 22, 2006 10:56 AM
To: Pappas, Bill
Cc: jra@samba.org; samba@lists.samba.org
Subject: Re: [Samba] tdb/tdbutil.c:tdb_chainlock_with_timeout_internal

On Fri, Jul 21, 2006 at 06:17:09PM -0500, Pappas, Bill
wrote:
> I will say this works for weeks on end w/o a problem.  When you say
this will not work, why? I've had no real problems with the veritas
clustered fs.  It adheres to file locking and fcntl operations like any
normal local filesystem (ext3).

Then it might be an intermittent bug in Veritas. What system call is
smbd hanging on ? smbd should never hang in the D wait state unless
it's a filesystem bug.

Jeremy.

Jeremy,

I was in a position (last night) to upgrade to 3.0.23a. 
Again, I was using 3.0.21c.

If smbd goes into the D state, we can at least eliminate the possibility
that it is an unexpected 3.0.21c bug.   


Thanks,
Bill Pappas - System Integration Engineer - SAN 
St. Jude Children's Research Hospital
332 North Lauderdale
Memphis, TN 38105
Danny Thomas Tower - Room D1010
Mail Stop 312

-----Original Message-----
From: Pappas, Bill 
Sent: Saturday, July 22, 2006 4:01 PM
To: Jeremy Allison
Cc: samba@lists.samba.org
Subject: RE: [Samba] tdb/tdbutil.c:tdb_chainlock_with_timeout_internal

Jeremy Allison wrote:
>>Then it might be an intermittent bug in Veritas. What system call is
>>smbd hanging on ? smbd should never hang in the D wait state unless
>>it's a filesystem bug.
I am beginning to believe that this could make sense. Let me emphasize
that ./private/secrets.tdb is shared between two samba servers (via
clustered vxfs) that are running independently.  Only one server runs
nmbd at a time as veritas cluster server fails nmbd over between servers
as needed.  I just figured keeping smbd running up on both servers to
reduce failover time.  I discovered that I had to share secrets.tdb to
ensure that either samba server would remain as a domain member server.
Is there another way to do what I am doing?  I'd gladly stop sharing
this file if I could keep smbd up on both servers.  Does smbd need a
lock on secrets.tdb? I thought (probably wrong) that only nmbd relied on
this file?

Further below, you will find some more logs between clients and the
server running nmbd and smbd (as the other was sitting idle with smbd
running). SJMEMDC05 is a windows domain controller and the other clients
are windows explorer clients. 

When you see these logs, they appear to confirm that secrets.tcb is
directly involved, but how would a locking issue with this file cause
smbd to go to the D state (and stay)?

log.hc-dfinkletest:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
tdb_lock failed on list 78 ltype=1 (Interrupted system call)
log.hc-dfinkletest:  tdb_chainlock_with_timeout_internal: alarm (10)
timed out for key SJMEMDC05 in tdb
/usr/local/samba-3.0.21c/private/secrets
.tdb
log.hc-dfinkletest:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
tdb_lock failed on list 78 ltype=1 (Interrupted system call)
log.hc-dfinkletest:  tdb_chainlock_with_timeout_internal: alarm (10)
timed out for key SJMEMDC05 in tdb
/usr/local/samba-3.0.21c/private/secrets
.tdb
log.hc-dfinkletest:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
tdb_lock failed on list 78 ltype=1 (Interrupted system call)
log.hc-dfinkletest:  tdb_chainlock_with_timeout_internal: alarm (10)
timed out for key SJMEMDC05 in tdb
/usr/local/samba-3.0.21c/private/secrets
.tdb
log.hc-mwang1:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
tdb_lock failed on list 78 ltype=1 (Interrupted system call)
log.hc-mwang1:  tdb_chainlock_with_timeout_internal: alarm (10) timed
out for key SJMEMDC05 in tdb
/usr/local/samba-3.0.21c/private/secrets.tdb
log.hc-mwang1:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
tdb_lock failed on list 78 ltype=1 (Interrupted system call)
log.hc-mwang1:  tdb_chainlock_with_timeout_internal: alarm (10) timed
out for key SJMEMDC05 in tdb
/usr/local/samba-3.0.21c/private/secrets.tdb
log.hc-mwang1:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
tdb_lock failed on list 78 ltype=1 (Interrupted system call)
log.hc-mwang1:  tdb_chainlock_with_timeout_internal: alarm (10) timed
out for key SJMEMDC05 in tdb
/usr/local/samba-3.0.21c/private/secrets.tdb
log.hc-mwang1:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
tdb_lock failed on list 78 ltype=1 (Interrupted system call)
log.hc-mwang1:  tdb_chainlock_with_timeout_internal: alarm (10) timed
out for key SJMEMDC05 in tdb
/usr/local/samba-3.0.21c/private/secrets.tdb
log.hc-mwang1:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
tdb_lock failed on list 78 ltype=1 (Interrupted system call)
log.hc-mwang1:  tdb_chainlock_with_timeout_internal: alarm (10) timed
out for key SJMEMDC05 in tdb
/usr/local/samba-3.0.21c/private/secrets.tdb
log.hc-mwang1:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
tdb_lock failed on list 78 ltype=1 (Interrupted system call)
log.hc-mwang1:  tdb_chainlock_with_timeout_internal: alarm (10) timed
out for key SJMEMDC05 in tdb
/usr/local/samba-3.0.21c/private/secrets.tdb

Thanks,
Bill Pappas - System Integration Engineer - SAN 
St. Jude Children's Research Hospital
332 North Lauderdale
Memphis, TN 38105
Danny Thomas Tower - Room D1010
Mail Stop 312

-----Original Message-----
From: Jeremy Allison [mailto:jra@samba.org] 
Sent: Saturday, July 22, 2006 10:56 AM
To: Pappas, Bill
Cc: jra@samba.org; samba@lists.samba.org
Subject: Re: [Samba] tdb/tdbutil.c:tdb_chainlock_with_timeout_internal

On Fri, Jul 21, 2006 at 06:17:09PM -0500, Pappas, Bill
wrote:
> I will say this works for weeks on end w/o a problem.  When you say
this will not work, why? I've had no real problems with the veritas
clustered fs.  It adheres to file locking and fcntl operations like any
normal local filesystem (ext3).

Then it might be an intermittent bug in Veritas. What system call is
smbd hanging on ? smbd should never hang in the D wait state unless
it's a filesystem bug.

Jeremy.

Thanks for the reply.

I will keep this in mind the next time this happens (your strace suggestion).

I upgraded from 3.0.21c to 3.0.23a as there were several bug fixes that could be
tied to this locking issue with vxfs, though the release notes do not discuss
much on file locking.  The issue will probably return even with the upgrade, but
it does address some other issues I've been having in 3.0.21c.

I guess now I am in wait and see mode.

I will ask Veritas about something similar to the GPFS locking parameter you
mentioned.

Thanks,
Bill Pappas - System Integration Engineer - SAN 
St. Jude Children's Research Hospital
332 North Lauderdale
Memphis, TN 38105
Danny Thomas Tower - Room D1010
Mail Stop 312

-----Original Message-----
From: Hansj?rg Maurer [mailto:hansjoerg.maurer@dlr.de] 
Sent: Monday, July 24, 2006 3:04 PM
To: Pappas, Bill
Cc: samba@lists.samba.org
Subject: Re: [Samba] tdb/tdbutil.c:tdb_chainlock_with_timeout_internal

Hi

we had an comparable issue with gpfs clusterfilesystem from IBM at 
11/2005 I posted on samba technical (subject tdb_lock problem on gpfs 
filesystem). Smbd went to D state sometimes to in this case.
Mostly  we recognized the problem with the tdb files of the printer ( 
the samba server was acting as a printserver to)

I got the following information from the IBM gpfs list:
"Also, Samba uses fcntl locking extensively on these files and may be 
maintaining thousands of individual locks. GPFS specifically sets a 
limit on the number of fcntl ranges allowed on a file at one time (to 
prevent a runaway or deviant application from consuming large amounts of 
resources recording such locks). I expect you are exceeding this limit, 
but you can configure a larger value: "mmchconfig 
maxFcntlRangesPerFile=10000.
The default is 200 and the acceptable range is currently 10-200000"

Increasing this (undocumented) value to 10000 solves the problem in our 
case.

Maybe there is a similar restriction with vertiasFS.

Have you tried to start smbd with an

strace -e fcntl -f smbd


to trace down the system call?
In our case it shows something like

fcntl(18, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=936, len=1}) -1 ENOLCK
(No locks available)

which indicates a problem with the filesystem.

Greetings

Hansj?rg











Pappas, Bill wrote:
>Jeremy,
>
>I was in a position (last night) to upgrade to 3.0.23a. 
>Again, I was using 3.0.21c.
>
>If smbd goes into the D state, we can at least eliminate the possibility
>that it is an unexpected 3.0.21c bug.   
>
>
>Thanks,
>Bill Pappas - System Integration Engineer - SAN 
>St. Jude Children's Research Hospital
>332 North Lauderdale
>Memphis, TN 38105
>Danny Thomas Tower - Room D1010
>Mail Stop 312
>
>-----Original Message-----
>From: Pappas, Bill 
>Sent: Saturday, July 22, 2006 4:01 PM
>To: Jeremy Allison
>Cc: samba@lists.samba.org
>Subject: RE: [Samba] tdb/tdbutil.c:tdb_chainlock_with_timeout_internal
>
>Jeremy Allison wrote:
>  
>
>>>Then it might be an intermittent bug in Veritas. What system call is
>>>smbd hanging on ? smbd should never hang in the D wait state unless
>>>it's a filesystem bug.
>>>      
>>>
>
>I am beginning to believe that this could make sense. Let me emphasize
>that ./private/secrets.tdb is shared between two samba servers (via
>clustered vxfs) that are running independently.  Only one server runs
>nmbd at a time as veritas cluster server fails nmbd over between servers
>as needed.  I just figured keeping smbd running up on both servers to
>reduce failover time.  I discovered that I had to share secrets.tdb to
>ensure that either samba server would remain as a domain member server.
>Is there another way to do what I am doing?  I'd gladly stop sharing
>this file if I could keep smbd up on both servers.  Does smbd need a
>lock on secrets.tdb? I thought (probably wrong) that only nmbd relied on
>this file?
>
>Further below, you will find some more logs between clients and the
>server running nmbd and smbd (as the other was sitting idle with smbd
>running). SJMEMDC05 is a windows domain controller and the other clients
>are windows explorer clients. 
>
>When you see these logs, they appear to confirm that secrets.tcb is
>directly involved, but how would a locking issue with this file cause
>smbd to go to the D state (and stay)?
>
>log.hc-dfinkletest:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
>tdb_lock failed on list 78 ltype=1 (Interrupted system call)
>log.hc-dfinkletest:  tdb_chainlock_with_timeout_internal: alarm (10)
>timed out for key SJMEMDC05 in tdb
>/usr/local/samba-3.0.21c/private/secrets
>.tdb
>log.hc-dfinkletest:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
>tdb_lock failed on list 78 ltype=1 (Interrupted system call)
>log.hc-dfinkletest:  tdb_chainlock_with_timeout_internal: alarm (10)
>timed out for key SJMEMDC05 in tdb
>/usr/local/samba-3.0.21c/private/secrets
>.tdb
>log.hc-dfinkletest:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
>tdb_lock failed on list 78 ltype=1 (Interrupted system call)
>log.hc-dfinkletest:  tdb_chainlock_with_timeout_internal: alarm (10)
>timed out for key SJMEMDC05 in tdb
>/usr/local/samba-3.0.21c/private/secrets
>.tdb
>log.hc-mwang1:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
>tdb_lock failed on list 78 ltype=1 (Interrupted system call)
>log.hc-mwang1:  tdb_chainlock_with_timeout_internal: alarm (10) timed
>out for key SJMEMDC05 in tdb
>/usr/local/samba-3.0.21c/private/secrets.tdb
>log.hc-mwang1:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
>tdb_lock failed on list 78 ltype=1 (Interrupted system call)
>log.hc-mwang1:  tdb_chainlock_with_timeout_internal: alarm (10) timed
>out for key SJMEMDC05 in tdb
>/usr/local/samba-3.0.21c/private/secrets.tdb
>log.hc-mwang1:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
>tdb_lock failed on list 78 ltype=1 (Interrupted system call)
>log.hc-mwang1:  tdb_chainlock_with_timeout_internal: alarm (10) timed
>out for key SJMEMDC05 in tdb
>/usr/local/samba-3.0.21c/private/secrets.tdb
>log.hc-mwang1:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
>tdb_lock failed on list 78 ltype=1 (Interrupted system call)
>log.hc-mwang1:  tdb_chainlock_with_timeout_internal: alarm (10) timed
>out for key SJMEMDC05 in tdb
>/usr/local/samba-3.0.21c/private/secrets.tdb
>log.hc-mwang1:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
>tdb_lock failed on list 78 ltype=1 (Interrupted system call)
>log.hc-mwang1:  tdb_chainlock_with_timeout_internal: alarm (10) timed
>out for key SJMEMDC05 in tdb
>/usr/local/samba-3.0.21c/private/secrets.tdb
>log.hc-mwang1:  tdb(/usr/local/samba-3.0.21c/private/secrets.tdb):
>tdb_lock failed on list 78 ltype=1 (Interrupted system call)
>log.hc-mwang1:  tdb_chainlock_with_timeout_internal: alarm (10) timed
>out for key SJMEMDC05 in tdb
>/usr/local/samba-3.0.21c/private/secrets.tdb
>
>Thanks,
>Bill Pappas - System Integration Engineer - SAN 
>St. Jude Children's Research Hospital
>332 North Lauderdale
>Memphis, TN 38105
>Danny Thomas Tower - Room D1010
>Mail Stop 312
>
>-----Original Message-----
>From: Jeremy Allison [mailto:jra@samba.org] 
>Sent: Saturday, July 22, 2006 10:56 AM
>To: Pappas, Bill
>Cc: jra@samba.org; samba@lists.samba.org
>Subject: Re: [Samba] tdb/tdbutil.c:tdb_chainlock_with_timeout_internal
>
>On Fri, Jul 21, 2006 at 06:17:09PM -0500, Pappas, Bill wrote:
>  
>
>>I will say this works for weeks on end w/o a problem.  When you say
>>    
>>
>this will not work, why? I've had no real problems with the veritas
>clustered fs.  It adheres to file locking and fcntl operations like any
>normal local filesystem (ext3).
>
>Then it might be an intermittent bug in Veritas. What system call is
>smbd hanging on ? smbd should never hang in the D wait state unless
>it's a filesystem bug.
>
>Jeremy.
>
>
>  
>