[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: repeated database problems...

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-04-22 20:47:51 CEST

On Thu, 2004-04-22 at 13:28, Perry E. Metzger wrote:
> Several times recently, my users have ended up getting this:
> $ svn commit foo
> Sending foo
> Transmitting file data .svn: Commit failed (details follow):
> svn: Berkeley DB error while committing Berkeley DB transaction for filesystem /svn/db:
> DB_RUNRECOVERY: Fatal error, run database recovery
> svn: Your commit message was left in a temporary file:
> [...]
> svnadmin recover fixes things right up.
> Anyone know what might be causing this, or possible solutions? I'll
> happily collect whatever information might be needed to debug it...

I'm about to commit this as a FAQ. Here's my first draft:

My repository seems to get stuck all the time, giving me errors about
needing recovery (DB_RUNRECOVERY). What could be the cause?

The BerkeleyDB database in your repository is susceptible to
interruptions. If a process accessing the database exits without
"cleanly" closing the environment, then the database is left in an
inconsistent state. Common causes of this include:

  * the process crashing/segfaulting
  * the process being forcibly killed
  * the process exiting when it hits a permission problem

To make the repository function again, simply run "svnadmin recover".
This rewinds the repository back to a consistent state. (See
#wedged-repos for more information about this.)

The _best_ way to prevent this problem is to get your repository
permissions and ownership set up correctly. Segfaults and forced
killings are pretty rare; far and away, this problem almost always
results from one process accessing the repository and accidentally
changing ownership or permissions. Then another process tries to
access and chokes on the permissions.

Here are our recommendations:

  * Try to have as *few* users access the repository as possible. For
    example, run apache or 'svnserve -d' as a specific user, and make
    the repository wholly owned by that user. Don't allow any other
    users to access the repository via file:/// urls, and be sure to
    run 'svnlook' and 'svnadmin' as the user which owns the

  * If your clients are accessing via file:/// or svn+ssh://, then
    there's no way to avoid access by multiple users. In that case,
    read the last section in chapter 6 (URL), and pay particular
    attention to the "checklist" box at the bottom. It outlines a
    number of steps to make this scenario safer.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 22 20:50:14 2004

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.