[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: tesh tesfaye <tesh_at_jedatechnologies.net>
Date: 2005-11-30 14:52:03 CET


Thank you for your recommendations. I was contemplating to switch to
FSFS and experiment when your email
arrived. I've exhausted all means including db_recover -c, which fixed
my db but did not solve my checkout

Anyhow while doing the command you recommended:
svnadmin dump repo > repo.dump

I get the following message
svnadmin: Berkeley DB error for filesystem /volume/projects/VOB/vobs1/db
while opening environment:
Resource temporarily unavailable
svnadmin: bdb: unable to join the environment

I even changed the previleges on repo/db/__db* files to all 777 but to
no avail. I'm thinking that the db is
all screwed up and I will restore my backup and try once again. I'm just
curious if anyone else has seen problems
with dumping like the above error messages and what they mean.

Thanks much

John Szakmeister wrote:

>On Tuesday 29 November 2005 15:18, tesh tesfaye wrote:
>>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
>>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

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 30 15:17:23 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.