From: Volker Lendecke on
On Fri, Oct 23, 2009 at 03:28:18PM -0700, Ray Van Dolson wrote:
> I bet you're right. So theoretically if I figure out how to track down
> that lock, it is likely held by my NFS server...

No, the NFS server is not holding a lock.

> Hrm. But would it make sense that other smbd processes are apparently
> still accessing brlock.tdb OK for different files?

Yes, there can be many concurrent accesses to brlock.tdb to
different hash chains.

> My low level understanding of the locking is lacking a bit. :)
>
> Anyways, I'm guessing if this turns out to be NFS related as we
> suspect, the only fix is to _not_ share with NFS. :)

You need to find the one holding the lock the others are
waiting for and see what that guy is blocking on. Everything
else is pure speculation.

Volker
From: Volker Lendecke on
On Fri, Oct 23, 2009 at 03:19:03PM -0700, Ray Van Dolson wrote:
> Hmm, yes, there is some of that. I guess I was thrown off by the fact
> that the lock appeared to be on the .tdb file and the .tdb file
> wouldn't be accessed by any NFS client.
>
> Could another process be holding the lock on the .tdb file while it
> waits for access to the underlying file within the requested share?

That's exactly what I'm thinking. An smbd holding the
brlock.tdb lock, waiting for pread while your NFS server has
gone to lunch.

Volker
From: Ray Van Dolson on
On Fri, Oct 23, 2009 at 03:34:29PM -0700, Volker Lendecke wrote:
> You need to find the one holding the lock the others are
> waiting for and see what that guy is blocking on. Everything
> else is pure speculation.

It appears mdb is what I want to use. See this[1] page if anyone is
curious.

Unfortunately, I kill -9'd one of the processes that was hung. As a
result the parent died and all its children, so the fouled up
environment I was in is now gone.

I'll wait for this to reoccur and then see if I can track down the
culprit.

Thanks for the guidance,

Ray

[1] http://utcc.utoronto.ca/~cks/space/blog/solaris/ListingFileLocks
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
From: Ray Van Dolson on
On Fri, Oct 23, 2009 at 02:41:46PM -0700, Volker Lendecke wrote:
> On Fri, Oct 23, 2009 at 02:18:19PM -0700, Ray Van Dolson wrote:
> > # pfiles -F 25067
> > 10: S_IFREG mode:0644 dev:85,60 ino:4630 uid:0 gid:0 size:327680
> > O_RDWR|O_LARGEFILE
> > advisory read lock set by process 21130
> > /var/samba/locks/brlock.tdb
>
> Ahhh. What does process 21130 do right now?
>

That is (was) the PID of the parent smbd process -- the one that spawns
all others.

Ray
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
From: Ray Van Dolson on
On Fri, Oct 23, 2009 at 03:21:35PM -0700, Volker Lendecke wrote:
> On Fri, Oct 23, 2009 at 03:19:03PM -0700, Ray Van Dolson wrote:
> > Hmm, yes, there is some of that. I guess I was thrown off by the fact
> > that the lock appeared to be on the .tdb file and the .tdb file
> > wouldn't be accessed by any NFS client.
> >
> > Could another process be holding the lock on the .tdb file while it
> > waits for access to the underlying file within the requested share?
>
> That's exactly what I'm thinking. An smbd holding the
> brlock.tdb lock, waiting for pread while your NFS server has
> gone to lunch.
>
> Volker

I bet you're right. So theoretically if I figure out how to track down
that lock, it is likely held by my NFS server...

Hrm. But would it make sense that other smbd processes are apparently
still accessing brlock.tdb OK for different files?

My low level understanding of the locking is lacking a bit. :)

Anyways, I'm guessing if this turns out to be NFS related as we
suspect, the only fix is to _not_ share with NFS. :)

Ray
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba