From: Volker Lendecke on 24 Oct 2009 13:30 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 24 Oct 2009 13:30 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 24 Oct 2009 13:40 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 24 Oct 2009 13:40 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 24 Oct 2009 13:40 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
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: [Samba] Help needed with log.winbindd errors Next: samba+ldap |