[Samba] tdb/tdbutil.c:tdb_chainlock_with_timeout_internal

[Pappas, Bill]

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 at samba.org>
To: Pappas, Bill <Bill.Pappas at STJUDE.ORG>
CC: samba at lists.samba.org <samba at 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.