On 10 Sep 2002, Ben Collins-Sussman wrote:
> Michael Süß <mai99dsr@ilabws.informatik.uni-leipzig.de> writes:
>
> > [Tue Sep 10 13:10:33 2002] [error] [client 10.10.11.73] could not open dbm
> > files. [500, #120022]
> > [Tue Sep 10 13:10:33 2002] [error] [client 10.10.11.73] (22)Invalid
> > argument: failed to open activity db; check repos perms. [500, #1
> > 20022]
> >
> > The obvious conclusion for me was, that the apache httpd doesn't have
> > enough rights to write to my repository, however the whole repository path
> > belongs to user nobody allready (and apache runs as nobody). Even a chmod
> > -R 777 to the whole path did not help.
>
> Specifically, the httpd process is unable to open the files within the
> 'dav' subdirectory of your repository. If they are all truly chmod'd
> 777, then perhaps it's a version problem... i.e. svnadmin used some
> database was used to create them (gdbm? bdb?) and httpd/mod_dav_svn is
> trying to use a different database library to open them via APR.
>
> Perhaps an 'ldd svnadmin' can show you what it's using?
Actually the dav-directory is still empty, but it belongs to user nobody
and the rights are all set. The outputs of ldd svnadmin follows:
libsvn_repos-1.so.0 => /usr/local/lib/libsvn_repos-1.so.0 (0x40017000)
libsvn_fs-1.so.0 => /usr/local/lib/libsvn_fs-1.so.0 (0x40024000)
libsvn_delta-1.so.0 => /usr/local/lib/libsvn_delta-1.so.0
(0x4003f000)
libdb-4.0.so => /usr/lib/libdb-4.0.so (0x40052000)
libsvn_subr-1.so.0 => /usr/local/lib/libsvn_subr-1.so.0
(0x400eb000)
libaprutil-0.so.0 => /usr/local/apache2/lib/libaprutil-0.so.0
(0x40103000)
libexpat.so.0 => /usr/local/apache2/lib/libexpat.so.0 (0x40118000)
libapr-0.so.0 => /usr/local/apache2/lib/libapr-0.so.0 (0x40136000)
libm.so.6 => /lib/libm.so.6 (0x40153000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40176000)
libnsl.so.1 => /lib/libnsl.so.1 (0x401aa000)
libdl.so.2 => /lib/libdl.so.2 (0x401c0000)
libpthread.so.0 => /lib/libpthread.so.0 (0x401c4000)
libc.so.6 => /lib/libc.so.6 (0x401da000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
ldd mod_dav_svn.so gives me:
libsvn_repos-1.so.0 => /usr/local/lib/libsvn_repos-1.so.0 (0x40011000)
libsvn_fs-1.so.0 => /usr/local/lib/libsvn_fs-1.so.0 (0x4001e000)
libsvn_delta-1.so.0 => /usr/local/lib/libsvn_delta-1.so.0
(0x40039000)
libsvn_subr-1.so.0 => /usr/local/lib/libsvn_subr-1.so.0
(0x40046000)
libc.so.6 => /lib/libc.so.6 (0x40065000)
libaprutil-0.so.0 => /usr/local/apache2/lib/libaprutil-0.so.0
(0x4018d000)
libdb-4.0.so => /usr/lib/libdb-4.0.so (0x401a2000)
libexpat.so.0 => /usr/local/apache2/lib/libexpat.so.0 (0x4023a000)
libapr-0.so.0 => /usr/local/apache2/lib/libapr-0.so.0 (0x40258000)
libm.so.6 => /lib/libm.so.6 (0x40275000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40299000)
libnsl.so.1 => /lib/libnsl.so.1 (0x402cc000)
libdl.so.2 => /lib/libdl.so.2 (0x402e2000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
As far as I can see this should be ok, and they are using the same
libraries.
> Another tactic is to run 'httpd -X' within gdb, and break on
> dav_svn_get_txn(). You can step into apr_dbm_open() and see what's
> happening.
Actually I did not really want to start debugging the apache httpd, but if
nothing else comes up, I guess I might have to start doing just that. But
first, any other ideas? Please?
Thanks in advance,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 11 10:50:29 2002