John,
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
problem.
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
/tesh
John Szakmeister wrote:
>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 15:17:23 2005