[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN and Debian

From: Wichert Akkerman <wichert_at_wiggy.net>
Date: 2003-05-09 11:26:28 CEST

Previously Ben Collins-Sussman wrote:
> Wichert, have you looked at the 'Repository Permissions' section of
> the subversion book?
> http://svnbook.red-bean.com/html-chunk/ch05s05.html

I have, and we follow those rules. Actually the recipe described there
does not work very well for us, since svn.debian.org will assemble a
large number of repositories and putting the user apache uses in all
groups is not possible. So what we have to do is make everything owned
by the apache user so access through DAV works, and use a group so
people with commit access can use svnserve. Unfortunately that leads
to the problem that db creates new files, which will be owned by the
wrong user so we've had to setup a crontab that fixes the permissions
on a regular basis.

But we did verify that all permissions are correct when this problem

> Although this may not be your problem; you make it sound like httpd is
> somehow not closing the berkeley environment propertly, leaving a lock
> behind.

At that moment apache still has a filehandle open on the lockfile, so
even if the permissions have been changed after apache opened the
lockfile that should not matter.

> In my experience, I've only ever seen this when an httpd
> child process outright segfaults. I wonder if your apache logs
> indicate this...?

I just rechecked our logs and apache does not segfault.


Wichert Akkerman <wichert@wiggy.net>      It is simple to make things.
http://www.wiggy.net/                     It is hard to make things simple.
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 9 15:34:52 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.