A little more elaboration... Commits work fine, then something happens such
that the permissions of new transactions cause commits to fail.
1)If I delete the transaction - e.g.
svnlook: Reference to non-existent node '0.0.t189-1' in filesystem
'access/db'
repos$ ls -l access/db/transactions/189-1.txn/props
-rw-r--r-- 1 root apache 0 Sep 8 11:02 access/db/transactions/189-1.txn
/props
repos$ rm -rf access/db/transactions/189-1.txn
2)**AND** restart apache everything works again for a while. Restarting
apache is **key**. If this were a permission problem created by an external
process touching the svn repository file system, I would expect it to stay
broken until I fixed the the permissions with chown/chmod.
This really sounds like a bug in apache and or subversion - perhaps exposed
by incompatible version of the libraries - like libapr (my apache is using
0.9.4)?
At this point, I'm going to try running subversion in its stand alone
svnserve. Hopefully the problem goes away.
Ben, just a follow up, my backup script now runs as the apache user:
$ cat /etc/cron.daily/svnbackup.sh
#!/bin/sh
#Execute the following command as the apache user
sudo -u apache /usr/bin/perl /svnroot/utils/svnscripts/svndaily.pl
-John
On 9/8/05, John Duprey <john.duprey@gmail.com> wrote:
>
> 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?
> >
> >
>
Received on Thu Sep 8 17:39:30 2005