Ben,
Thanks for responding.
There are two other processes that access the subversion repository:
websvn, and a perl script that backs up the repositories using
svnadmin nightly. I'll have a closer look at the back up script
tomorrow. Websvn (http://websvn.tigris.org) is just apache/php and
runs subversions command line tools (svnlook,etc). It *does* access
the repository through the local file system using those tools.
I've given it quite some consideration which external processes could
be causing this. The back up script and websvn are the only ones I've
come up with. I would think that if it was either of these, they
would cause this error consistently - that they would bust the
repository outright and that all commits to that repository would
fail.
As I've noted in the details, it is a file in the current transaction
(the current commit) that has the wrong permissions. Its not like
all of repos/db/transactions/ has the wrong permissions. The specific
transaction directory, the one just created for the commit inside of
db/transacations, has the correct permissions. Its one of the files,
props, created *inside* of that dir that has the wrong permissions...
and this problem only shows up sporadically.
I'll keep looking for any other external processes. At this point,
I'm considering running svnserve - taking subversion out of apache to
see if that helps.
Thanks for following up and if you have any more ideas for what to
look for, I'd be glad to hear them.
-John
On 9/7/05, Ben Collins-Sussman <sussman@collab.net> wrote:
>
> On Sep 7, 2005, at 12:08 PM, John Duprey wrote:
> >
> > -rw-r--r-- 1 root apache 0 Sep 7 14:32 props
> >
> > Notice that props is own by root and only root has write perms.
> > That is suspect.
>
> It certainly is.
>
>
> > Can *anyone* think of why this could be other than a bug in apache
> > and or mod_svn/subversion?
>
> Sure. You have some other process, somewhere, which is occasionally
> accessing the repository as the 'root' user. Perhaps it's somebody
> (or a script, or cron job) running 'svnadmin' or 'svnlook' as root.
> Perhaps it's something accessing directly using file:/// URLs, or
> running svn+ssh:// from some other box.
>
> My recommendation is that you do a full audit of the system: are you
> *positive* that no process other than httpd *ever* touches the
> repository?
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 8 07:16:45 2005