You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by John Duprey <jo...@gmail.com> on 2005/09/06 19:40:22 UTC
Re: Svn transaction failure due, mod_svn - apache 2
This is a follow up to my own post. I'm at a loss for what to try next. If
anyone can provide a fresh perspective, I'd appreciate it!
I uninstalled apache, php, and subversion, moved the old config dirs out of
the way and re-installed, apache, php, and subversion. We are still getting
periodic errors similar to:
[Wed Aug 31 12:55:55 2005] [error] [client
192.189.224.121<http://192.189.224.121/>]
Could not create activity /svn/ResultsPlus/!svn/act
>
> /a24ba835-0155-2042-a734-13818c448007. [500, #0]
In 99.9% of the cases we also see props is owned by root:
repos$ ls -l ResultsPlus/db/transactions/90-1.txn/
total 0
-rw-r--r-- 1 root apache 0 Aug 31 12:56 props
Can *anyone* think of why this could be other than a bug in apache and or
mod_svn/subversion? I think I've given most of the pertinent information,
see below. I'd appreciate any help or suggestions for debugging the problem.
(We use tortoise-svn for the client, we also use websvn (on the server) for
browsing logs, etc.)
Here's what I think are the relevant details:
subversion.conf
# Needed to do Subversion Apache server.
LoadModule dav_svn_module modules/mod_dav_svn.so
# Only Needed if you decide to do "per-directory" access control.
#LoadModule authz_svn_module modules/mod_authz_svn.so
#
# Example location directive.
#
<Location /svn>
DAV svn
SVNParentPath /svnroot/repos
# # Limit write permission to list of valid users.
<LimitExcept GET PROPFIND OPTIONS REPORT>
# # Require SSL connection for password protection.
# # SSLRequireSSL
#
# AuthType Basic
# AuthName "Authorization Realm"
# AuthUserFile /absolute/path/to/passwdfile
AuthType Basic
AuthName "Authorization Realm"
AuthUserFile /etc/svnpass
Require valid-user
</LimitExcept>
</Location>
On 8/31/05, John Duprey <jo...@gmail.com> wrote:
>
> Hello,
>
> I'm having the strangest problem with a number of our subversion
> repositories all running one of our apache-linux server (askani).
> Occasionally transactions fail with error messages similar to:
> [Wed Aug 31 12:55:55 2005] [error] [client 192.189.224.121<http://192.189.224.121>]
> Could not create activity
> /svn/ResultsPlus/!svn/act/a24ba835-0155-2042-a734-13818c448007. [500, #0]
> [Wed Aug 31 12:55:55 2005] [error] [client 192.189.224.121<http://192.189.224.121>]
> could not begin a transaction [500, #13]
> [Wed Aug 31 12:55:55 2005] [error] [client 192.189.224.121<http://192.189.224.121>]
> Can't open file '/svnroot/repos/ResultsPlus/db/transactions/90-1.txn/node.0.0':
> Permission denied [500, #13]
>
> File permissions are set correctly. User and group is set to the apache
> user and permissions are set such that user and group can read, write, and
> change directories (rwX). In trying to diagnose the problem I even gave
> (everybody) rwX permissions. Looking in the repos/db/transactions directory
> I can see the start of a transaction:
>
> repos$ ls -l ResultsPlus/db/transactions/
> total 4
> drw-rwSrw- 2 apache apache 4096 Aug 31 12:56 90-1.txn
>
> **Sometimes** a props file exists within the transaction dir:
>
> repos$ ls -l ResultsPlus/db/transactions/90-1.txn/
> total 0
> -rw-r--r-- 1 root apache 0 Aug 31 12:56 props
>
> Notice the owner/permissions of the the props file! That isn't right is
> it.
>
> This problem doesn't happen all the time, but when it does the only way to
> recover is to delete the transaction (e.g. 90-1.txn) and restart the
> apache server.
>
> I'm running RedHat Enterprise Linux 3.
> repos$ cat /etc/redhat-release
> Red Hat Enterprise Linux AS release 3 (Taroon Update 5)
>
> I'm running apache 2:
> Server Version: Apache/2.0.46 (Red Hat)
> Server Built: Feb 25 2005 09:35:45
> API Version: 20020903:4
>
> I'm running the latest prebuilt subversion libraries from
> http://summersoft.fay.ar.us/pub/subversion/latest/rhel-3/bin/:
> rpm -qa | grep -i subversion
> subversion-perl-1.2.1-1
> subversion-devel-1.2.1-1
> subversion-1.2.1-1
> subversion-python-1.2.1-1
> subversion-debuginfo-1.2.1-1
> subversion-tools-1.2.1-1
>
> (Note: I had the same problem with the 1.2.0 binaries, .. thought
> upgrading would help..)
>
> This server was running fine a for many weeks and I'm just now seeing the
> problem so I suspect I've mis-configured something or some apache module is
> causing flaky behavior. However, I can't seem to isolate the problem. I'm at
> a loss and would really appreciate some help and/or advice.
>
> Here are the apache modules installed:
> Server Settings <http://askani.roc.westgroup.com/server-info#server>,
> mod_authz_svn.c<http://askani.roc.westgroup.com/server-info#mod_authz_svn.c>,
> mod_dav_svn.c <http://askani.roc.westgroup.com/server-info#mod_dav_svn.c>,
> sapi_apache2.c<http://askani.roc.westgroup.com/server-info#sapi_apache2.c>,
> mod_cgi.c <http://askani.roc.westgroup.com/server-info#mod_cgi.c>,
> mod_mem_cache.c<http://askani.roc.westgroup.com/server-info#mod_mem_cache.c>,
> mod_file_cache.c<http://askani.roc.westgroup.com/server-info#mod_file_cache.c>,
> mod_disk_cache.c<http://askani.roc.westgroup.com/server-info#mod_disk_cache.c>,
> mod_suexec.c <http://askani.roc.westgroup.com/server-info#mod_suexec.c>,
> mod_cache.c <http://askani.roc.westgroup.com/server-info#mod_cache.c>,
> proxy_connect.c<http://askani.roc.westgroup.com/server-info#proxy_connect.c>,
> proxy_http.c <http://askani.roc.westgroup.com/server-info#proxy_http.c>,
> proxy_ftp.c <http://askani.roc.westgroup.com/server-info#proxy_ftp.c>,
> mod_proxy.c <http://askani.roc.westgroup.com/server-info#mod_proxy.c>,
> mod_rewrite.c <http://askani.roc.westgroup.com/server-info#mod_rewrite.c>,
> mod_alias.c <http://askani.roc.westgroup.com/server-info#mod_alias.c>,
> mod_userdir.c <http://askani.roc.westgroup.com/server-info#mod_userdir.c>,
> mod_speling.c <http://askani.roc.westgroup.com/server-info#mod_speling.c>,
> mod_actions.c <http://askani.roc.westgroup.com/server-info#mod_actions.c>,
> mod_imap.c <http://askani.roc.westgroup.com/server-info#mod_imap.c>,
> mod_dir.c <http://askani.roc.westgroup.com/server-info#mod_dir.c>,
> mod_negotiation.c<http://askani.roc.westgroup.com/server-info#mod_negotiation.c>,
> mod_vhost_alias.c<http://askani.roc.westgroup.com/server-info#mod_vhost_alias.c>,
> mod_dav_fs.c <http://askani.roc.westgroup.com/server-info#mod_dav_fs.c>,
> mod_info.c <http://askani.roc.westgroup.com/server-info#mod_info.c>,
> mod_asis.c <http://askani.roc.westgroup.com/server-info#mod_asis.c>,
> mod_autoindex.c<http://askani.roc.westgroup.com/server-info#mod_autoindex.c>,
> mod_status.c <http://askani.roc.westgroup.com/server-info#mod_status.c>,
> mod_dav.c <http://askani.roc.westgroup.com/server-info#mod_dav.c>,
> mod_mime.c <http://askani.roc.westgroup.com/server-info#mod_mime.c>,
> mod_setenvif.c<http://askani.roc.westgroup.com/server-info#mod_setenvif.c>,
> mod_unique_id.c<http://askani.roc.westgroup.com/server-info#mod_unique_id.c>,
> mod_usertrack.c<http://askani.roc.westgroup.com/server-info#mod_usertrack.c>,
> mod_headers.c <http://askani.roc.westgroup.com/server-info#mod_headers.c>,
> mod_deflate.c <http://askani.roc.westgroup.com/server-info#mod_deflate.c>,
> mod_expires.c <http://askani.roc.westgroup.com/server-info#mod_expires.c>,
> mod_cern_meta.c<http://askani.roc.westgroup.com/server-info#mod_cern_meta.c>,
> mod_mime_magic.c<http://askani.roc.westgroup.com/server-info#mod_mime_magic.c>,
> mod_env.c <http://askani.roc.westgroup.com/server-info#mod_env.c>,
> mod_log_config.c<http://askani.roc.westgroup.com/server-info#mod_log_config.c>,
> mod_include.c <http://askani.roc.westgroup.com/server-info#mod_include.c>,
> mod_auth_digest.c<http://askani.roc.westgroup.com/server-info#mod_auth_digest.c>,
> mod_auth_dbm.c<http://askani.roc.westgroup.com/server-info#mod_auth_dbm.c>,
> mod_auth_anon.c<http://askani.roc.westgroup.com/server-info#mod_auth_anon.c>,
> mod_auth.c <http://askani.roc.westgroup.com/server-info#mod_auth.c>,
> mod_access.c <http://askani.roc.westgroup.com/server-info#mod_access.c>,
> mod_so.c <http://askani.roc.westgroup.com/server-info#mod_so.c>,
> http_core.c <http://askani.roc.westgroup.com/server-info#http_core.c>,
> prefork.c <http://askani.roc.westgroup.com/server-info#prefork.c>, core.c<http://askani.roc.westgroup.com/server-info#core.c> Thanks in advance,
> -John
>
>
>
>
Re: Svn transaction failure due to wrong permissions on creation.
Posted by John Duprey <jo...@gmail.com>.
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 <jo...@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 <su...@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?
> >
> >
>
Re: Svn transaction failure due to wrong permissions on creation.
Posted by John Duprey <jo...@gmail.com>.
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 <jo...@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 <su...@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?
> >
> >
>
Re: Svn transaction failure due to wrong permissions on creation.
Posted by John Duprey <jo...@gmail.com>.
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 <su...@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
Re: Svn transaction failure due to wrong permissions on creation.
Posted by Ben Collins-Sussman <su...@collab.net>.
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
Svn transaction failure due to wrong permissions on creation.
Posted by John Duprey <jo...@gmail.com>.
Hello developer-type people,
If this is a case of me not RTFM, I apologize. I *think* I've looked
everywhere for a solution. Can someone please take pity on me and help me
solve this problem? I posted this problem to the users mailing list and
heard total silence. I'm re-sending hear in hopes that this problem might
ring a bell.
We are using subversion 1.2.2 server and the latest tortoise svn and
subclipse. *Occasionally* we get an error on commit. On the client side it
reports "svn: commit failed. .. MKACTIVITY of
'/svn/CFA/!svn/act/a4c8.....334': 500 Internal Server Error.."
On the server side I see in the appache error logs (using subversion as part
of apache):
[Wed Sep 07 14:24:10 2005] [error] [client
10.222.128.106<http://10.222.128.106>]
Could not create activity
/svn/CFA/!svn/act/192122a9-0b54-7a4c-9699-0ccc0ad19655. [500, #0]
[Wed Sep 07 14:24:10 2005] [error] [client
10.222.128.106<http://10.222.128.106>]
could not begin a transaction [500, #13]
[Wed Sep 07 14:24:10 2005] [error] [client
10.222.128.106<http://10.222.128.106>]
Can't open file '/svnroot/repos/CFA/db/transactions/148-1.txn/node.0.0':
Permission denied [500, #13]
Listing open transactions reveals:
---[ CFA/ Transaction 148-1 ]-------------------------------------------
svnlook: Reference to non-existent node '0.0.t148-1' in filesystem 'CFA/db'
Looking at the filesystem reveals:
ls -l CFA/db/transactions/148-1.txn/
total 0
-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. I have chown'ed -R apache:apache /svnroot/repos - the parent dir of
all my repositories. I have chmod'ed -R ug+rwX /svnroot/repos.
More details about the installation, software versions, etc can be found
below. I've tried lots of things - removing configuration options out of
HTTPD (like virtual hosts, user dirs, etc). I did a complete re-install of
apache, php, subversion. I'm at a loss and would appreciate any help anyone
can provide.
My next blind step is to run svnserve stand alone.
---------- Forwarded message ----------
From: John Duprey <jo...@gmail.com>
Date: Sep 6, 2005 3:40 PM
Subject: Re: Svn transaction failure due, mod_svn - apache 2
To: users@subversion.tigris.org
This is a follow up to my own post. I'm at a loss for what to try next. If
anyone can provide a fresh perspective, I'd appreciate it!
I uninstalled apache, php, and subversion, moved the old config dirs out of
the way and re-installed, apache, php, and subversion. We are still getting
periodic errors similar to:
[Wed Aug 31 12:55:55 2005] [error] [client
192.189.224.121<http://192.189.224.121/>]
Could not create activity /svn/ResultsPlus/!svn/act
>
> /a24ba835-0155-2042-a734-13818c448007. [500, #0]
In 99.9% of the cases we also see props is owned by root:
repos$ ls -l ResultsPlus/db/transactions/90-1.txn/
total 0
-rw-r--r-- 1 root apache 0 Aug 31 12:56 props
Can *anyone* think of why this could be other than a bug in apache and or
mod_svn/subversion? I think I've given most of the pertinent information,
see below. I'd appreciate any help or suggestions for debugging the problem.
(We use tortoise-svn for the client, we also use websvn (on the server) for
browsing logs, etc.)
Here's what I think are the relevant details:
subversion.conf
# Needed to do Subversion Apache server.
LoadModule dav_svn_module modules/mod_dav_svn.so
# Only Needed if you decide to do "per-directory" access control.
#LoadModule authz_svn_module modules/mod_authz_svn.so
#
# Example location directive.
#
<Location /svn>
DAV svn
SVNParentPath /svnroot/repos
# # Limit write permission to list of valid users.
<LimitExcept GET PROPFIND OPTIONS REPORT>
# # Require SSL connection for password protection.
# # SSLRequireSSL
#
# AuthType Basic
# AuthName "Authorization Realm"
# AuthUserFile /absolute/path/to/passwdfile
AuthType Basic
AuthName "Authorization Realm"
AuthUserFile /etc/svnpass
Require valid-user
</LimitExcept>
</Location>
On 8/31/05, John Duprey <jo...@gmail.com> wrote:
>
> Hello,
>
> I'm having the strangest problem with a number of our subversion
> repositories all running one of our apache-linux server (askani).
> Occasionally transactions fail with error messages similar to:
> [Wed Aug 31 12:55:55 2005] [error] [client 192.189.224.121<http://192.189.224.121>]
> Could not create activity
> /svn/ResultsPlus/!svn/act/a24ba835-0155-2042-a734-13818c448007. [500, #0]
> [Wed Aug 31 12:55:55 2005] [error] [client 192.189.224.121<http://192.189.224.121>]
> could not begin a transaction [500, #13]
> [Wed Aug 31 12:55:55 2005] [error] [client 192.189.224.121<http://192.189.224.121>]
> Can't open file '/svnroot/repos/ResultsPlus/db/transactions/90-1.txn/node.0.0':
> Permission denied [500, #13]
>
> File permissions are set correctly. User and group is set to the apache
> user and permissions are set such that user and group can read, write, and
> change directories (rwX). In trying to diagnose the problem I even gave
> (everybody) rwX permissions. Looking in the repos/db/transactions directory
> I can see the start of a transaction:
>
> repos$ ls -l ResultsPlus/db/transactions/
> total 4
> drw-rwSrw- 2 apache apache 4096 Aug 31 12:56 90-1.txn
>
> **Sometimes** a props file exists within the transaction dir:
>
> repos$ ls -l ResultsPlus/db/transactions/90-1.txn/
> total 0
> -rw-r--r-- 1 root apache 0 Aug 31 12:56 props
>
> Notice the owner/permissions of the the props file! That isn't right is
> it.
>
> This problem doesn't happen all the time, but when it does the only way to
> recover is to delete the transaction (e.g. 90-1.txn) and restart the
> apache server.
>
> I'm running RedHat Enterprise Linux 3.
> repos$ cat /etc/redhat-release
> Red Hat Enterprise Linux AS release 3 (Taroon Update 5)
>
> I'm running apache 2:
> Server Version: Apache/2.0.46 (Red Hat)
> Server Built: Feb 25 2005 09:35:45
> API Version: 20020903:4
>
> I'm running the latest prebuilt subversion libraries from http://summersoft.fay.ar.us/pub/subversion/latest/rhel-3/bin/
> :
> rpm -qa | grep -i subversion
> subversion-perl-1.2.1-1
> subversion-devel-1.2.1-1
> subversion-1.2.1-1
> subversion-python-1.2.1-1
> subversion-debuginfo-1.2.1-1
> subversion-tools-1.2.1-1
>
> (Note: I had the same problem with the 1.2.0 binaries, .. thought
> upgrading would help..)
>
> This server was running fine a for many weeks and I'm just now seeing the
> problem so I suspect I've mis-configured something or some apache module is
> causing flaky behavior. However, I can't seem to isolate the problem. I'm at
> a loss and would really appreciate some help and/or advice.
>
> Here are the apache modules installed:
> Server Settings <http://askani.roc.westgroup.com/server-info#server>,
> mod_authz_svn.c<http://askani.roc.westgroup.com/server-info#mod_authz_svn.c>,
> mod_dav_svn.c <http://askani.roc.westgroup.com/server-info#mod_dav_svn.c>,
> sapi_apache2.c<http://askani.roc.westgroup.com/server-info#sapi_apache2.c>,
> mod_cgi.c <http://askani.roc.westgroup.com/server-info#mod_cgi.c>,
> mod_mem_cache.c<http://askani.roc.westgroup.com/server-info#mod_mem_cache.c>,
> mod_file_cache.c<http://askani.roc.westgroup.com/server-info#mod_file_cache.c>,
> mod_disk_cache.c<http://askani.roc.westgroup.com/server-info#mod_disk_cache.c>,
> mod_suexec.c <http://askani.roc.westgroup.com/server-info#mod_suexec.c>,
> mod_cache.c <http://askani.roc.westgroup.com/server-info#mod_cache.c>,
> proxy_connect.c<http://askani.roc.westgroup.com/server-info#proxy_connect.c>,
> proxy_http.c <http://askani.roc.westgroup.com/server-info#proxy_http.c>,
> proxy_ftp.c <http://askani.roc.westgroup.com/server-info#proxy_ftp.c>,
> mod_proxy.c <http://askani.roc.westgroup.com/server-info#mod_proxy.c>,
> mod_rewrite.c <http://askani.roc.westgroup.com/server-info#mod_rewrite.c>,
> mod_alias.c <http://askani.roc.westgroup.com/server-info#mod_alias.c>,
> mod_userdir.c <http://askani.roc.westgroup.com/server-info#mod_userdir.c>,
> mod_speling.c <http://askani.roc.westgroup.com/server-info#mod_speling.c>,
> mod_actions.c <http://askani.roc.westgroup.com/server-info#mod_actions.c>,
> mod_imap.c <http://askani.roc.westgroup.com/server-info#mod_imap.c>,
> mod_dir.c <http://askani.roc.westgroup.com/server-info#mod_dir.c>,
> mod_negotiation.c<http://askani.roc.westgroup.com/server-info#mod_negotiation.c>,
> mod_vhost_alias.c<http://askani.roc.westgroup.com/server-info#mod_vhost_alias.c>,
> mod_dav_fs.c <http://askani.roc.westgroup.com/server-info#mod_dav_fs.c>,
> mod_info.c <http://askani.roc.westgroup.com/server-info#mod_info.c>,
> mod_asis.c <http://askani.roc.westgroup.com/server-info#mod_asis.c>,
> mod_autoindex.c<http://askani.roc.westgroup.com/server-info#mod_autoindex.c>,
> mod_status.c <http://askani.roc.westgroup.com/server-info#mod_status.c>,
> mod_dav.c <http://askani.roc.westgroup.com/server-info#mod_dav.c>,
> mod_mime.c <http://askani.roc.westgroup.com/server-info#mod_mime.c>,
> mod_setenvif.c<http://askani.roc.westgroup.com/server-info#mod_setenvif.c>,
> mod_unique_id.c<http://askani.roc.westgroup.com/server-info#mod_unique_id.c>,
> mod_usertrack.c<http://askani.roc.westgroup.com/server-info#mod_usertrack.c>,
> mod_headers.c <http://askani.roc.westgroup.com/server-info#mod_headers.c>,
> mod_deflate.c <http://askani.roc.westgroup.com/server-info#mod_deflate.c>,
> mod_expires.c <http://askani.roc.westgroup.com/server-info#mod_expires.c>,
> mod_cern_meta.c<http://askani.roc.westgroup.com/server-info#mod_cern_meta.c>,
> mod_mime_magic.c<http://askani.roc.westgroup.com/server-info#mod_mime_magic.c>,
> mod_env.c <http://askani.roc.westgroup.com/server-info#mod_env.c>,
> mod_log_config.c<http://askani.roc.westgroup.com/server-info#mod_log_config.c>,
> mod_include.c <http://askani.roc.westgroup.com/server-info#mod_include.c>,
> mod_auth_digest.c<http://askani.roc.westgroup.com/server-info#mod_auth_digest.c>,
> mod_auth_dbm.c<http://askani.roc.westgroup.com/server-info#mod_auth_dbm.c>,
> mod_auth_anon.c<http://askani.roc.westgroup.com/server-info#mod_auth_anon.c>,
> mod_auth.c <http://askani.roc.westgroup.com/server-info#mod_auth.c>,
> mod_access.c <http://askani.roc.westgroup.com/server-info#mod_access.c>,
> mod_so.c <http://askani.roc.westgroup.com/server-info#mod_so.c>,
> http_core.c <http://askani.roc.westgroup.com/server-info#http_core.c>,
> prefork.c <http://askani.roc.westgroup.com/server-info#prefork.c>, core.c<http://askani.roc.westgroup.com/server-info#core.c> Thanks in advance,
> -John
>
>
>
>