You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Perry E. Metzger" <pe...@piermont.com> on 2004/04/22 18:28:22 UTC
repeated database problems...
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...
--
Perry E. Metzger perry@piermont.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repeated database problems...
Posted by Ben Collins-Sussman <su...@collab.net>.
On Thu, 2004-04-22 at 14:34, Perry E. Metzger wrote:
> Okay, based on what you've said, I've found a possible permissions
> problem (see below). However, as a point of principle, the repository
> should really be able to recover itself. If one of my users hits ^C at
> the wrong point, the repo should not get curdled. If the system knows
> enough to know it needs to run recover, it should know enough to lock
> the database and actually run the recover.
This has been the subject of much debate in the past. Originally, we
deliberately decided not to do this, because N different processes could
be accessing the database at any given moment. Running recovery
requires exclusive access, and there's no way for one process to be
aware of all the others.
That was the early days; more recently, our database readers/writers
take out a lock in the repos/locks/ area. If you run 'svnadmin
recover', then in theory, svnadmin waits for all locks to vanish before
running recovery. So I suppose this *could* happen now... we'd need to
rediscuss.
Really, this is all the "dark side" of using an embedded database. The
"good side" is that you don't need to set up a whole SQL subsystem to
get database features of your repository. The bad news is that because
there isn't a single process mediating all table access (e.g. something
like mysqld), it's easy for processes to mess things up for each other.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repeated database problems...
Posted by "Perry E. Metzger" <pe...@piermont.com>.
Okay, based on what you've said, I've found a possible permissions
problem (see below). However, as a point of principle, the repository
should really be able to recover itself. If one of my users hits ^C at
the wrong point, the repo should not get curdled. If the system knows
enough to know it needs to run recover, it should know enough to lock
the database and actually run the recover.
Also, the error message should be a bit friendlier to the users --
the message is way too scary given that it is not a fatal condition.
Ben Collins-Sussman <su...@collab.net> writes:
> 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.
My procs are all using the sgid wrapper I contributed to the system,
but there is also, from what I can tell, a small flaw with it -- the
umask isn't being set. I don't know that this is my problem but it
might be. You might want to add the following patch to my contributed
wrapper:
--- svnserve-wrapper.c (revision 17)
+++ svnserve-wrapper.c (revision 94)
@@ -31,6 +31,9 @@
#include <stdio.h>
#include <unistd.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+
#ifdef DEBUG
#define REAL_PATH "/bin/sh"
#else
@@ -64,6 +67,9 @@
fprintf(stderr, "gid = %d, euid = %d\n", i, j);
#endif
+ /* Make sure things are created group writable. */
+ umask(0002);
+
execve(REAL_PATH, argv, newenv);
perror("attempting to exec " REAL_PATH " failed");
return 1;
> 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.
--
Perry E. Metzger perry@piermont.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repeated database problems...
Posted by Ben Collins-Sussman <su...@collab.net>.
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