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 <sussman@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
Received on Thu Apr 22 21:35:27 2004