You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by tesh tesfaye <te...@jedatechnologies.net> on 2005/11/29 20:18:22 UTC
SVN wedged, please help
Hi there,
After trying out for over 8 hours trying to restore our svn setup I have
to turn to those more experienced svn user. I had done all the reading
I could get on issues of wedged databases etc. thinking that I've
encountered that problem but that's not getting me anywhere.
back to square one
Subversion version 1.2.1
Apache Version 2.0.48
Subversion currently installed on Redhat 9.0 (fileserver machine) while
the Webserver is on a Redhat 8.0 machine.
Oursetup had worked without any flaw until two days ago where "svn co"
was failing with the following error messages
despite that the file was reachable via an http session.
-------------
svn co <repository>
svn: REPORT request failed on '/svn/!svn/vcc/default'
svn: Can't find a temporary directory
--------------
I was guessing that I had exhausted the number of locks perhaps, so
rebooted the file server to no avail.
Everything I read suggested doing recovery so I backed up my reposiotry
and did that. First round of recovery run I did pointed
out to a couple of lock files in the <repository>/db file(locks and
lock-tokens both owned by apache). The output from the recover
command was as follows:
---------------
Repository lock acquired.
Please wait; recovering the repository may take some time...
Recovery completed.
svnadmin: Berkeley DB error for filesystem /space/projects/VOB/vobs1/db
while opening 'locks' table:
Permission denied
----------------
I temporarily renames the locks to see the effect of rerunning the
recovery process once again to get the following log message:
----------------
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?
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.
Thanks much
/tesh
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN wedged, please help
Posted by John Szakmeister <jo...@szakmeister.net>.
On Wednesday 30 November 2005 14:46, tesh tesfaye wrote:
> Garrett,
>
> Thanks for pointing this subtle point. I did some more reading on
> http://svnbook.red-bean.com/ and your
> point was explained in detail that using BDB is bad with NFS :( I'm
> moving to FSFS and am running into
> weird problems trying to dump from BDB and get the error 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
tesh,
Did you change your original setup at all? Did you move your repository from
one machine to another? Had you been trying to use it via NFS?
There are a couple of things to realize about BDB. It's sensitive to version,
and platform. You can't just move your repository from one version to the
next without some additional work. And you can't move between cpu
architectures without a dump and load of the database. And as Garrett said,
you can't use it on an NFS mount.
If you changed versions of BDB in the process of trying to move things around,
you likely need to go through an upgrade process first, or you need to use
the original machine to dump the repository. Also, a good example of how to
do a catastrophic recovery can also be found in the FAQ:
http://subversion.tigris.org/faq.html#bdb-recovery
I'd recommend that if you have a copy of the original broken repository,
before you ran all of these recover commands on it, that you start again with
that. If you haven't been doing this on the machine that originally held the
repository, I suggest you move back to the original machine and do the dump
there. If for some reason you can't do that, then use your new machine, but
run through the upgrade process. Normally, that means running svnadmin
recover. However, if the new machine has BDB 4.3.x, then you need to look at
this:
http://subversion.tigris.org/faq.html#bdb43-upgrade
If you want to dump the data directly from BDB, you can also try the db_dump
command.
HTH.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN wedged, please help
Posted by tesh tesfaye <te...@jedatechnologies.net>.
Garrett,
Thanks for pointing this subtle point. I did some more reading on
http://svnbook.red-bean.com/ and your
point was explained in detail that using BDB is bad with NFS :( I'm
moving to FSFS and am running into
weird problems trying to dump from BDB and get the error 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 am going to do more reading on BDB and force it to dump.
Thanks again everyone for all your suggestions and help
Cheers
/tesh
Garrett Rooney wrote:
>On 11/29/05, tesh tesfaye <te...@jedatechnologies.net> wrote:
>
>
>
>>Subversion currently installed on Redhat 9.0 (fileserver machine) while
>>the Webserver is on a Redhat 8.0 machine.
>>
>>
>
>Does that imply that you're serving your repository from one machine,
>but that machine accesses the repository via NFS mounts or something?
>If so, that's a very bad idea with BDB, Berkeley DB doesn't tend to
>play nicely with NFS drives...
>
>-garrett
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN wedged, please help
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 11/29/05, tesh tesfaye <te...@jedatechnologies.net> wrote:
> Subversion currently installed on Redhat 9.0 (fileserver machine) while
> the Webserver is on a Redhat 8.0 machine.
Does that imply that you're serving your repository from one machine,
but that machine accesses the repository via NFS mounts or something?
If so, that's a very bad idea with BDB, Berkeley DB doesn't tend to
play nicely with NFS drives...
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN wedged, please help
Posted by tesh tesfaye <te...@jedatechnologies.net>.
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
Re: SVN wedged, please help
Posted by John Szakmeister <jo...@szakmeister.net>.
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