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
repository.
* 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