Peter Schuller <peter.schuller@infidyne.com> writes:
> all of a sudden when I was going to do an "svn update" today svn started
> hanging. I can do "svn status" but not an "update". Probably becauset he
> former is local. I did a strace and got:
>
> open("/home/infidyne/svn/db/__db.001", O_RDWR|O_LARGEFILE) = 3
> fcntl64(0x3, 0x2, 0x1, 0x2) = 0
> mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x40133000
> close(3) = 0
> select(0, NULL, NULL, NULL, {0, 1000}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {0, 2000}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {0, 4000}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {0, 8000}) = 0 (Timeout)
Try:
- shutting down your server
- su to the user who owns the repository
- cd to the `db' subdirectory of the repository
- run db_recover -ve (make sure to use the db_recover that comes with
the version of Berkeley DB that you built Subversion itself with)
- restart the server
> Looks like it's waiting on a db lock.
That's what we think, too.
From the Subversion handbook, which doesn't mention that you should
shut down the server while you do these things:
@c ------------------------------------------------------------------
@node Repository maintenance
@section Repository maintenance
@subsection Berkeley DB management
At the time of writing, the subversion repository has only one
database back-end: Berkeley DB. All of your filesystem's structure
and data live in a set of tables within @file{repos/db/}.
Berkeley DB comes with a number of tools for managing these files, and
they have their own excellent documentation. (See
@uref{http://www.sleepycat.com/}, or just read man pages.) We won't
cover all of these tools here; rather, we'll mention just a few of the
more common procedures that repository administrators might need.
First, remember that Berkeley DB has genuine transactions. Every
attempt to change the DB is first logged. If anything ever goes
wrong, the DB can back itself up to a previous `checkpoint' and
replay transactions to get the data back into a sane state.
In our experience, we have seen situations where a bug in Subversion
(which causes a crash) can sometimes have a side-effect of leaving the
DB environment in a `locked' state. Any further attempts to read or
write to the repository just sit there, waiting on the lock.
To `unwedge' the repository, use @command{db_recover}:
@example
$ db_recover -ve -h repos/db
db_recover: Finding last valid log LSN: file: 40 offset 4080873
db_recover: Checkpoint at: [40][4080333]
db_recover: Checkpoint LSN: [40][4080333]
db_recover: Previous checkpoint: [40][4079793]
db_recover: Checkpoint at: [40][4079793]
db_recover: Checkpoint LSN: [40][4079793]
db_recover: Previous checkpoint: [40][4078761]
db_recover: Recovery complete at Sun Jul 14 07:15:42 2002
db_recover: Maximum transaction id 80000000 Recovery checkpoint [40][4080333]
@end example
Make sure you run this command as the user that owns and manages the
database and @emph{not} as root. Running @command{db_recover} as root
will leave root owned files in the db directory which cannot be opened
by the non-root user that manages the database, which is typically
your Apache process.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 29 23:39:26 2002