[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Problem with svnadmin recover

From: Jamie Lawrence <jal_at_clueinc.net>
Date: 2004-09-24 21:22:10 CEST

Hi all,

(My first post to the list.)

I'm having problems with svnserve recover. Corruption happened
(permissions issue), and now the recover process hangs waiting on the
lock file.

$ strace /usr/local/bin/svnadmin.real recover .
[...]
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40086000
write(1, "Please wait; recovering the repo"..., 61Please wait; recovering the repository may take some time...
) = 61
brk(0x8061000) = 0x8061000
brk(0x8069000) = 0x8069000
open("format", O_RDONLY) = 3
read(3, "3\n", 80) = 2
close(3) = 0
brk(0x806c000) = 0x806c000
open("locks/db.lock", O_RDWR) = 3

The lockfile doesn't appear to have anything interesting in it:

[root@pluto locks]# cat db.lock
DB lock file, representing locks on the versioned filesystem.

All accessors -- both readers and writers -- of the repository's
Berkeley DB environment take out shared locks on this file, and
each accessor removes its lock when done. If and when the DB
recovery procedure is run, the recovery code takes out an
exclusive lock on this file, so we can be sure no one else is
using the DB during the recovery.

You should never have to edit or remove this file.

This is svn 1.0.6, built by hand on RH AS 2.1.

-j

-- 
Jamie Lawrence                                        jal@jal.org
Let not the sands of time get in your lunch.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Sep 24 21:22:52 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.