Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm trying to commit to a SVN server. On the server the subversion repository is NFS mounted. When doing a commit, I get this error message:

svn: Can't get exclusive lock on file '/svn/repo/db/transactions/7802-2.txn/rev-lock': No locks available

This used to work, and there has been no software upgrades / changes on anything. However the NFS server did crash earlier, so it might be 'corrupted' (if that's even applicable here)

share|improve this question
add comment

4 Answers 4

up vote 6 down vote accepted

There's a few possibilities here:

  1. The user account that is doing the SVN update may not have update permission on the repository directory
  2. The NFS file system where the repository is stored may be full
  3. The lock daemon (lockd) may not be running on the NFS server.

UPDATE: following the update to the question, I'd suspect #3. Make sure that lockd is set up to start when the NFS server is rebooted.

share|improve this answer
    
"ps aux | grep lockd" on the server has output, so i think it's running –  Rory Sep 2 '09 at 17:06
add comment

Make sure that your NFS server supports locks; you may need to enable additional processes on the NFS server to accomplish this; see rpc.lockd(8) and rpc.statd(8).

Additionally, if your NFS server has restarted recently, you may have a stale or even a partially stale NFS mount. Try unmounting and remounting the NFS mount as well.

EDIT: based on your other question, it looks like lockd didn't start after your NFS server recovered from it's crash.

share|improve this answer
    
It used to work, until the nfs server crashed. there's been no software updates recently. I've expanded the question –  Rory Sep 2 '09 at 16:47
    
Your NFS mount might be (partially) stale; happens over here with a FreeBSD based NFS server and Solaris clients. Umounting / remounting the NFS share fixes the problem for us. –  Tel Janin Sep 2 '09 at 16:52
    
restarting the client that had the NFS mount didn't fix it. (Although there are other machines that are mounting from that NFS server that I haven't restarted/remounted) –  Rory Sep 2 '09 at 17:08
add comment

There are a number of alternatives mentioned in this google search for terms you mentioned above.

A few of the options mentioned are: full discs, permissions issues, "hung" or "stuck" svnserve processes, and hung transactions... You may need to try a number of these different issues to see what exactly the problem is in your case.

It sounds like you are using the bsddb SVN back-end? You may want to try migrating your repository over to the fsfs back-end (the default for several years now). It has, in my experience and from that of a number of others I know, proven more reliable than bsddb. Though you'll want to research how it interacts with NFS -- I haven't used it on NFS.

Another option you may want to consider is moving away from using SVN over NFS and instead running it over SSH on a server with the SVN repository locally stored. This is how we do all our SVN work, with fsfs backend, and I can't remember the last time we had SVN repository issues.

Sean

share|improve this answer
    
we're using FSFS back end –  Rory Sep 3 '09 at 10:10
add comment

if you using SVN with NFS on debian

run this:

/etc/init.d/portmap restart
share|improve this answer
1  
It can be helpful to explain why you suggest this as your answer. –  Drew Khoury Sep 30 '13 at 8:32
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.