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

Re: Importing/Commiting using the net-interface not working

From: Michael S <mai99dsr_at_ilabws.informatik.uni-leipzig.de>
Date: 2002-09-11 10:52:44 CEST

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] could not open dbm
> > files. [500, #120022]
> > [Tue Sep 10 13:10:33 2002] [error] [client] (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
        libdb-4.0.so => /usr/lib/libdb-4.0.so (0x40052000)
        libsvn_subr-1.so.0 => /usr/local/lib/libsvn_subr-1.so.0
        libaprutil-0.so.0 => /usr/local/apache2/lib/libaprutil-0.so.0
        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
        libsvn_subr-1.so.0 => /usr/local/lib/libsvn_subr-1.so.0
        libc.so.6 => /lib/libc.so.6 (0x40065000)
        libaprutil-0.so.0 => /usr/local/apache2/lib/libaprutil-0.so.0
        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
> 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,


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

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.