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

Re: SVN wedged, please help

From: John Szakmeister <john_at_szakmeister.net>
Date: 2005-11-30 12:03:00 CET

On Tuesday 29 November 2005 15:18, tesh tesfaye wrote:
[snip]
> ----------------
> Repository lock acquired.
> Please wait; recovering the repository may take some time...
>
> Recovery completed.
> svnadmin: Berkeley DB error for filesystem /volume/projects/VOB/vobs1/db
> while opening 'locks' table:
> DB_RUNRECOVERY: Fatal error, run database recovery
> svnadmin: bdb: /volume/projects/VOB/vobs1/db/log.0000000271: log file
> open failed: Permission denied
> svnadmin: bdb: PANIC: Permission denied
> svnadmin: bdb: DB_ENV->log_put:
> /volume/projects/VOB/vobs1/db/log.0000000271: DB_RUNRECOVERY: Fatal
> error, run database recovery
> svnadmin: bdb: locks: DB_RUNRECOVERY: Fatal error, run database recovery
> Abort
> ------------
>
> I am now left with doing a catastrophic recovery on bdb and before I go
> ahead to do that I would like to ask the following:
> 1. Has anyone encountered similar problem, and if so how did they solve it?

Similar issues have turned up in the past. Simply put, BDB is very sensitive
about permission-related issues. The problem is that even some read-only
operations require the ability to write to the log files in order to create
the transaction. However, that doesn't mean a log file goes unused after the
transaction is done, so what ends up happening is you get a permissions
conflict between the maintainer and the hosting environment. The recommended
way of handling this is to have the maintainer run the necessary operations
as the same user as Apache.

> 2. There are a number of log. files in the <respository>/db that are of
> different userid's: the maintainer of the repository and apache.
> I am anticipating conflicts or perimission problems as shown above
> to persisit, any clues of getting aroudn this.

If you aren't particularly interested in modifying the process that the
maintainer is using to avoid permission conflicts, then your only alternative
is to switch to FSFS. It handles the permission issue much better, and by
design, can never become wedged.

svnadmin dump repo > repo.dump
svnadmin create --fs-type fsfs new-repo
svnadmin load new-repo < repo.dump

-John

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 30 12:47:05 2005

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.