Newlyn Erratt wrote on Tue, Dec 23, 2014 at 18:19:19 +0000:
> All,
>
> I had a server failure recently and ended up having to restore from a
> hotcopy. Everything went well I did an svnadmin verify with no issues.
> I am able to checkout and update with no issues but when I try to
> commit I get the following message:
>
Did you use 'svnadmin hotcopy' to generate the hotcopy? Or did you
use some ad-hoc method such as cp/tar/rsync. (Asking to rule out the
possibility that the backup's rep-cache.db is corrupted.)
> post-commit FS processing had error 'database is locked'.
>
> I get this even with a freshly checked out copy and svn cleanup gives nothing. I tried running svn recover just in case with no changes. The actual commit seems to happen fine even with this error message.
>
> I'm not super familiar with administering svn so I'm not sure at all where to go from here.
>
> Thanks for any assistance,
> Newlyn
"post-commit FS processing" suggests the error concerns rep-cache.db,
which is an auxiliary SQLite database in the repository. The effect of
the error is that newly-committed revisions won't use rep-sharing.
The error is server-side, unrelated to the working copy.
"database is locked" means svn couldn't write to the sqlite db because
some other process is holding a lock. (You would probably see similar
errors in your server's error log, from when svn tried to read the db
earlier in the commit process.) Normally that is due to contention
(i.e., the lock is held by another server process), but it sounds like
in your case it might be a stale lock that has somehow persisted through
the hotcopy-and-restore cycle?
As a workaround, you could disable rep-sharing in fsfs.conf. That will
bypass rep-cache.db completely.
What output do you get if you run
% sudo -u svn sqlite3 $REPOS_DIR/db/rep-cache.db "select max(revision) from rep_cache;"
? Do you get a different output if you stop httpd/svnserve before
running the command?
(You might have to install the sqlite3 command-line tool if you don't
already have it installed.)
You might want to add a few more details, such as versions of svnadmin,
sqlite3, and the nature of the server failure (knowing what happened
might help us understand the failure mode you are seeing).
Good luck!
Daniel
Received on 2014-12-24 01:52:48 CET