You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Will Glass-Husain <wg...@forio.com> on 2005/09/28 19:27:17 UTC
repository corrupted repeatedly
Hi,
I'm having trouble with a repeatedly corrupting repository. I've searched the mailing list and issues tracker haven't got any insights.
Setup: Linux (Suse 9.2) with Subversion 1.0.8, Apache 2.0.49, Berkeley DB 4.2. I haven't updated Subversion since I can't seem to find a later Suse RPM. (I may try compiling if I get desperate).
The problem. Three times in the past few days my (recently created) repository has become corrupted. Symptoms:
(1)
svn command line:
$ svn log
svn: PROPFIND request failed on '/svn/src1/loyalty/trunk'
svn: PROPFIND of '/svn/src1/loyalty/trunk': 500 Internal Server Error (https://www.dynamicsymmetry.symmetrics.com)
(2)
$ svnlook log /var/svn/src1
svn: Berkeley DB error while checkpointing after Berkeley DB transaction for filesystem /var/svn/src1/db: Invalid argument
svn: Berkeley DB error while closing 'nodes' database for filesystem /var/svn/src1/db: Invalid argument
(3)
A number of the "db" files ownership have been mysteriously changed from "wwwrun" to "root". Changing them back does not help.
(4)
Apache Log (date/time/ip omitted)
... (2)No such file or directory: cannot access type map file: HTTP_UNAUTHORIZED.htm
... Could not fetch resource information. [500, #0]
... Could not determine the proper revision to access [500, #160029]
... Berkeley DB error while checkpointing after Berkeley DB transaction for filesystem /var/svn/src1/db:\nInvalid argument [500, #160029]
... (20014)Error string not specified yet: Berkeley DB error while closing 'nodes' database for filesystem /var/svn/src1/db:\nInvalid argument
The Fix:
The last time I had this issue I recovered the database, then changed the permissions to be readable by the apache2 user.
$ su
$ cd /var/svn/src1/db
$ db_recovery -e -v
$ chown -R wwwrun .
This worked. The next time this happened it failed:
$ cd /var/svn/src1/db
$ db_recovery -e -v
db_recover: Finding last valid log LSN: file: 68 offset 102818
db_recover: Ignoring log file: log.0000000065: magic number 0, not 40988
db_recover: Invalid log file: log.0000000065: Invalid argument
db_recover: First log record not found
db_recover: PANIC: Invalid argument
db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run database recovery
Any tips for where I should investigate further? Or should I just grit my teeth and compile the latest subversion (scrapping the Suse RPM system).
Thanks, WILL
Re: repository corrupted repeatedly
Posted by lo...@yahoo.com.
Will Glass-Husain wrote:
>Hi,
>
>I'm having trouble with a repeatedly corrupting repository.
> [...]
> I haven't updated Subversion since I can't seem to find a later Suse RPM.
look for it on any suse ftp: mirror
pub/linux/suse/projects/apache/subversion/
since 2005-09-23 there is even version 1.2.3
HTH
Lorenz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repository corrupted repeatedly
Posted by Oliver Pajonk <ol...@gmail.com>.
2005/9/28, Will Glass-Husain <wg...@forio.com>:
>
>
> svn: Berkeley DB error while checkpointing after Berkeley DB transaction
> for filesystem /var/svn/src1/db: Invalid argument
> svn: Berkeley DB error while closing 'nodes' database for filesystem
> /var/svn/src1/db: Invalid argument
>
As always a goot suggestion is: do not use Berkeley DB as backend, use FSFS.
This fixed many problems with repository corruption for many others.
--
Oliver Pajonk
Re: repository corrupted repeatedly
Posted by Paul Koning <pk...@equallogic.com>.
>>>>> "Will" == Will Glass-Husain <wg...@forio.com> writes:
Will> More info: When I do a "ps aux" I see that I have 4 httpd
Will> processes. One runs as root (the initial process)" the others
Will> as "wwwrun".
Will> Of course, I have to start as root since this is over port 443.
Will> Could this be an Apache config issue? Sometimes accessing the
Will> files with root and sometimes wwwrun? (thus somehow corrupting
Will> the repository?) If so, ideas on config would be appreciated.
The extra httpd copies are worker threads.
In your httpd.conf you'll see "User" and "Group" lines. The "user"
will say "wwwrun" in your case. But only the worker threads should
ever be doing things, otherwise the whole security benefit of setting
the user ID like that would be lost.
In other words, I would expect that you have to have your repository
set up to be owned by wwwrun. Watch out for accesses by machinery
other than apache -- svnserve, or file:/// URLs. See the fine manual
for a discussion on that topic.
BTW, if Suse insists on shipping such an old version, maybe you need
to use a better source of code than their prebuilt packages. There
are Subversion packages that are up to date, see the "downloads" page
on the Subversion website. I just grabbed some nice 1.2.3 RPM files
from there, which worked as advertised (that was for RedHat of
course).
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repository corrupted repeatedly
Posted by Will Glass-Husain <wg...@forio.com>.
More info:
When I do a "ps aux" I see that I have 4 httpd processes. One runs as root (the initial process)" the others as "wwwrun".
Of course, I have to start as root since this is over port 443.
Could this be an Apache config issue? Sometimes accessing the files with root and sometimes wwwrun? (thus somehow corrupting the repository?) If so, ideas on config would be appreciated.
Best, WILL
----- Original Message -----
From: Will Glass-Husain
To: users@subversion.tigris.org
Sent: Wednesday, September 28, 2005 12:27 PM
Subject: repository corrupted repeatedly
Hi,
I'm having trouble with a repeatedly corrupting repository. I've searched the mailing list and issues tracker haven't got any insights.
Setup: Linux (Suse 9.2) with Subversion 1.0.8, Apache 2.0.49, Berkeley DB 4.2. I haven't updated Subversion since I can't seem to find a later Suse RPM. (I may try compiling if I get desperate).
The problem. Three times in the past few days my (recently created) repository has become corrupted. Symptoms:
(1)
svn command line:
$ svn log
svn: PROPFIND request failed on '/svn/src1/loyalty/trunk'
svn: PROPFIND of '/svn/src1/loyalty/trunk': 500 Internal Server Error (https://www.dynamicsymmetry.symmetrics.com)
(2)
$ svnlook log /var/svn/src1
svn: Berkeley DB error while checkpointing after Berkeley DB transaction for filesystem /var/svn/src1/db: Invalid argument
svn: Berkeley DB error while closing 'nodes' database for filesystem /var/svn/src1/db: Invalid argument
(3)
A number of the "db" files ownership have been mysteriously changed from "wwwrun" to "root". Changing them back does not help.
(4)
Apache Log (date/time/ip omitted)
... (2)No such file or directory: cannot access type map file: HTTP_UNAUTHORIZED.htm
... Could not fetch resource information. [500, #0]
... Could not determine the proper revision to access [500, #160029]
... Berkeley DB error while checkpointing after Berkeley DB transaction for filesystem /var/svn/src1/db:\nInvalid argument [500, #160029]
... (20014)Error string not specified yet: Berkeley DB error while closing 'nodes' database for filesystem /var/svn/src1/db:\nInvalid argument
The Fix:
The last time I had this issue I recovered the database, then changed the permissions to be readable by the apache2 user.
$ su
$ cd /var/svn/src1/db
$ db_recovery -e -v
$ chown -R wwwrun .
This worked. The next time this happened it failed:
$ cd /var/svn/src1/db
$ db_recovery -e -v
db_recover: Finding last valid log LSN: file: 68 offset 102818
db_recover: Ignoring log file: log.0000000065: magic number 0, not 40988
db_recover: Invalid log file: log.0000000065: Invalid argument
db_recover: First log record not found
db_recover: PANIC: Invalid argument
db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run database recovery
Any tips for where I should investigate further? Or should I just grit my teeth and compile the latest subversion (scrapping the Suse RPM system).
Thanks, WILL