Edgewall Software

Opened 18 years ago

Closed 18 years ago

Last modified 10 years ago

#741 closed defect (duplicate)

Database continually becomes corrupt

Reported by: jacob@… Owned by: Jonas Borgström
Priority: high Milestone:
Component: general Version: 0.7.1
Severity: critical Keywords: subversion database corruption
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:


On a fairly regular basis — seems like around once every few hours — something about trac causes the subversion database to corrupt, requiring a svnadmin recover to fix it.

This sounds like its related to Ticket #571 (although we're not on Windows); I've tried the umask/chmod g+s stuff that bje@apnic.net suggested on that ticket, and it's slowed down the rate of these errors, but not completely stopped them.

The error we keep getting is: ('Berkeley DB error while opening environment for filesystem /home/svn/repository/db:\nDB_RUNRECOVERY: Fatal error, run database recovery', 160029).

We're running Trac 0.7.1 (as a CGI) under Apache 2.0 on RedHat ES with Subversion 1.0.6.

Attachments (0)

Change History (12)

comment:1 by jacob@…, 18 years ago

Based on some help from #trac, I've done the following:

  1. chmod -R g+s /home/svn/repository

  2. Made sure that all local users are umask 002 (by adding that line to /etc/bashrc)

  3. Replaced svnserve with a wrapper that makes sure svnserve runs umask 002:

    umask 002
    /usr/bin/svnserve-real "$@"

This has (so far) seemed to work pretty well...

comment:2 by duff@…, 18 years ago

I had the same problem. I didn't want to change the default umask for all my processes so I added the following to the trac.cgi file:

import os; os.umask(007)

before the try statement. It solved the last of my problems (like you I got improved results from using the setgid bit on the db directory and changing svn/svnserve to scripts which set the umask).


Thomas Duff

comment:3 by jacob@…, 18 years ago


I'm not sure I totally understand how umasks work, but did you mean 002 instead of 007?

comment:4 by jacob@…, 18 years ago

Priority: normalhigh

Just to follow up… the above tricks have helped slow down the frequency somewhat, but this is still happening on a far-to-regular basis.

comment:5 by jacob@…, 18 years ago

Tickets #93 and #223 seem to be related to this one.

comment:6 by anonymous, 18 years ago

Resolution: fixed
Status: newclosed

comment:7 by anonymous, 18 years ago

Resolution: fixed
Status: closedreopened

Sorry, I didn't think it would actually let me close the ticket.

comment:8 by anonymous, 18 years ago

Here's more on the problem, with details of a workaround:


comment:9 by hendrik@…, 18 years ago

I'm encountering the same problem, and the permissions are all set up correctly as far as I can see (including the umask for all involved processes).

Using Trac 0.7.1 (CGI on Apache1) with Subversion 1.0.6 (Apache2 module). OS is Debian Sarge.

comment:10 by daniel, 18 years ago

Resolution: duplicate
Status: reopenedclosed

This is a dupe of #571, and still not a Trac bug. Please read the comment trail on #571.

comment:11 by daniel, 18 years ago

Milestone: 0.8

comment:12 by Christian Boos, 10 years ago

Milestone: 0.8

(clearing report:35)

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Jonas Borgström.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Jonas Borgström to the specified user.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.