Thursday
25Aug2005
Subversion and NFS file locking
Thursday, August 25, 2005 at 3:13PM
I should prefix this with a warning: I know next to nothing about file locking and the implications of what I've just done. However, it now appears to work, and I'm not too worried about simultaneous access to my subversion repository since I'm the only one that uses it. (Even the web interface is currently running from a read-only mirror of the repository.)
Since DreamHost have upgraded my shell machine to Sarge, my subversion repository has stopped working. Which is not entirely unexpected, since one of the libraries the
[code]mathie@Tandoori:mathie$ svn up
svn: Error opening db lockfile
svn: Can't get shared lock on file '/home/mathie/svnroot/locks/db.lock': No locks available[/code]
It couldn't successfully lock the repository. Now my subversion repository uses the fs_fs backend (rather than Berkeley DB), and it's on an NFS mount. It would appear that file locking isn't working over NFS in this particular situation. Looking at
[code]#define HAVE_FCNTL_H 1[/code]
Rebuild apr with a
Your job is to tell me how much I risk screwing up my repository having made this change...
Since DreamHost have upgraded my shell machine to Sarge, my subversion repository has stopped working. Which is not entirely unexpected, since one of the libraries the
svn binary dynamically linked to (libgdbm) had shifted its SO_NAME from 1 to 3 in the upgrade. OK, so a rebuild was done and the binaries were working. Except for one major problem:[code]mathie@Tandoori:mathie$ svn up
svn: Error opening db lockfile
svn: Can't get shared lock on file '/home/mathie/svnroot/locks/db.lock': No locks available[/code]
It couldn't successfully lock the repository. Now my subversion repository uses the fs_fs backend (rather than Berkeley DB), and it's on an NFS mount. It would appear that file locking isn't working over NFS in this particular situation. Looking at
apr/file_io/unix/flock.c, I see there's code to use either fcntl() or flock() to do the locking, but given the choice, it'll use fcntl(). So I tried out a wee test: readlock.c This attempts to create a read lock on a file using both methods. Both methods work fine on a local filesystem with my laptop (Mac OS X 10.4) and on the shell server (Debian GNU/Linux 3.1). However the fcntl() method fails on the latter machine when it's on an NFS mount. flock() does work. Yee ha. Solution? Edit apr/include/arch/unix/apr_private.h and comment out the line that reads:[code]#define HAVE_FCNTL_H 1[/code]
Rebuild apr with a
make clean && make && make install and your copy of subversion now 'works' (as in doesn't fail in the obvious way!) on an NFS-mounted filesystem.Your job is to tell me how much I risk screwing up my repository having made this change...
View Printer Friendly Version
Email Article to Friend
Reader Comments (10)
Kai: Obviously I don't speak for DreamHost. However, the only real fix is to arrange for the repositories to be on a local file system, which I suspect doesn't really fit in well with DH's network architecture (at a guess, most of the home directory storage is going to be sitting on NetApp servers?). So it could be a while.
Go vote for everything subversion related in the suggestions page on the control panel, just to let them know that we'd really like proper subversion hosting support. (Including all the bells and whistles -- anonymous http access, trac as a repository front end, that kind of thing!)
I don't see DH moving away from NFS. I don't have time to wait. Isn't there a work around?
I've hosted my repo with fsfs on NFS without these issues. :/
I'm not sure if this is helpful or not, and the Linux here is Redhat, but a quick man on flock mentions (at the bottom)
"flock(2) does not lock files over nfs. Use fcntl(2) instead: that does work over nsf, ..."
I am actually using a call to lockf(3) which end up (aledgedly) calling fcntl(2).
Take a look and good luck.
-craig
I solved this problem with changing the nfs mount option.
When the "svn: Unable to open an ra_local session to URL
svn: Unable to open repository ‘path/to/repo’
svn: Error opening db lockfile
svn: Can’t get shared lock on file ‘path/to/repo’: No locks available" message occured, I changed the NFS mount option from default to "hard,intr,bg,nolock,rw" and remount the nfs directory to my local mount point.
I sugget you apply this solution to your systems.
I agree that Byung-chul Lee's solution does work.
Subversion 1.2.1 running on a Fedora Core 3 server accessed from Ubuntu 5.10 Breezy Badger workstation with eSVN 0.6.8 and svn command-line client version 1.2.0.
wow, many thanks - Byung-chul Lee. It is a simple, elegant solution -- certainly saved a lot of head pounding! thanks again.
Thanks for the NFS mount option solution. Suddenly, I could no longer access repositories or create new ones across drives (but could still create locally). Your solution saved the day.
I am probably doing something wrong, but at our work we run the SVN server off a Windows Server machine (The best hardware for the job at the time), but I get that same error when I try to commit files when I work from a Mac. When I work from a PC I get no errors, only the Mac throws the "Can't get exclusive ock" error. Any suggestions?
(I wish Byung-chul Lee's suggestion applied to me, but I don't think it does)
I have the same issue than Nicolas. I recently bought a MacBook Air, and now develop PHP on it. I tried to use Eclipse with the PHP and SVN plugins and the SCPlugin which is the equivalent of the Tortoise SVN for Mac OS.
In both cases I have the "Can't get exclusive lock" error when trying to commit.
Some suggestion?
Just a pointer. The "nolock" option turns off file locking via NFS, so make sure you're not using the repository in a multitasking situation (running it via apache, will do just that... especially if more than one person wishes to write to the repository at the same time...)
/E