11

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)

6 Answers 6

16

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.

5
  • 1
    "ps aux | grep lockd" on the server has output, so i think it's running Sep 2, 2009 at 17:06
  • 1
    It was related to the NFS server.
    – Francisco
    Feb 27, 2016 at 4:06
  • 1
    My case was #3. Fixed by /sbin/service nfslock start in CentOS 6.8 (reference: 18.1.1. Required Services Apr 10, 2017 at 19:37
  • 2
    Another possibility is that the /var partition is full, since this is where statd stores information about NFS locks.
    – Connor
    Jun 17, 2020 at 19:35
  • Any suggestions on how to do this on Ubuntu18.04?
    – Valentyn
    Aug 21, 2020 at 16:43
3

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.

3
  • It used to work, until the nfs server crashed. there's been no software updates recently. I've expanded the question Sep 2, 2009 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, 2009 at 16:52
  • 1
    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) Sep 2, 2009 at 17:08
1

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

2
  • we're using FSFS back end Sep 3, 2009 at 10:10
  • +1 for full disks! turns out although the NFS mount wasn't full, the root drive was...
    – hwjp
    Oct 6, 2015 at 14:41
0

if you using SVN with NFS on debian

run this:

/etc/init.d/portmap restart
1
  • 1
    It can be helpful to explain why you suggest this as your answer. Sep 30, 2013 at 8:32
0

I had similar problems here, mine due to vagrant's NFS mounts. Going from what Tel Janin said above, I restarted rpcbind with sudo service rpcbind restart on my host OS. This hung my vm. I restarted that, which gave me a cryptic NFS error failed to start with result 'dependency'. It did work though and I'm now a happy camper.

0

I had same issue on NFS server restart, on my old debian 3.16.7 following helped:

/etc/init.d/nfs-kernel-server restart

then nfs client must remount volume, and it worked.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .