Mojca Miklavec <mojca.miklavec.lists_at_gmail.com> writes:
> We have a server running Fedora which has recently been upgraded to
> version 20 and it's now running
> svn, version 1.8.5 (r1542147)
>
> I have a bunch of repositories served over http protocol with public
> read access and limited commit access.
>
> Shortly after the upgrade a weird behaviour has been noticed. Running
> "svn up" on the top level dir worked ok for me, but running
> svn co http://svn.myserver.net/myrepo/dirA
> fails with
>
> A dirA/subdir1
> A dirA/subdir2
> A dirA/subdir3
> A dirA/subdir4
> svn: E000054: Error retrieving REPORT: Connection reset by peer
>
> The directory "dirA" contains one more file FILE.txt. Checking out any
> individual "subdirN" works and the browser is able to display the
> contents of dirA.
>
> Trying to click on FILE.txt in the browser sometimes works (it
> currently does) and sometimes shows an XML (like a few minutes ago,
> but I'm unable to get it now), saying something similar to the error I
> get in console***:
>
> svn: E175002: Unable to connect to a repository at URL
> 'svn.myserver.net/myrepo/dirA'
> svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on
> '/myrepo/dirA'
>
> svn: E160004: Additional errors:
> svn: E160004: Corrupt node-revision '2-1.0.r137/330061'
>
> (*** To be precise: this is the error I get after upgrading the
> repository to the latest version of SVN, I didn't try to get to this
> error before upgrading.)
>
> The error.log in apache says just:
>
> [<date>] [dav:error] [pid 3613] [client <ip:port>] Unable to deliver
> content. [500, #0]
> [<date>] [dav:error] [pid 3613] [client <ip:port>] Could not write
> data to filter. [500, #175002]
>
> I first tried if upgrading the repository would help in any way, so I did
> svnadmin dump oldrepo | svnadmin load newrepo
> and checking the relevant revision r137 cited in the error all I see
> is the following (nothing unusual):
>
> ------- Committed revision 136 >>>
>
> <<< Started new transaction, based on original revision 137
> * editing path : dirA/FILE.txt ... done.
> * Dumped revision 137.
> * editing path : dirA/subdir1/somefile ... done.
>
> ------- Committed revision 137 >>>
>
> Checking out the same repository via http on the machine where the
> repository itself is located works fine.
>
> I'm using the same version of SVN (1.8.5) on Mac, but other svn
> clients on other OSes have problems as well.
>
> I tried checking the repository health with
> svnadmin verify /path/to/myrepo
> and all revisions passed except for some weird error inbetween (the
> file rev-prop-atomics.mutex is actually missing, but it isn't present
> in any other repository either):
>
> * Verifying repository metadata ...
> * Verifying metadata at revision 1 ...
> ...
> * Verifying metadata at revision 155 ...
> svnadmin: E160052: Revprop caching for '/path/to/myrepo/db' disabled
> because SHM infrastructure for revprop caching failed to initialize.
> svnadmin: E000013: Can't open file
> '/path/to/myrepo/db/rev-prop-atomics.mutex': Permission denied
> * Verified revision 0.
> ...
> * Verified revision 160.
>
>
> I would appreciate any help or debugging hints. If necessary I can
> share the repository URL (but I would prefer to share it off-list to
> anyone interested in debugging). I can also try to debug myself, but I
> need some instructions telling me what to check. I didn't manage to
> find anything useful by googling the errors other than figuring out
> that the error was part of the code to fix a memory leak
> (http://svn.haxx.se/dev/archive-2009-08/0274.shtml).
I've not seen E000054 before but it is EXFULL which is some sort of
network error. I suppose the corruption causes some sort of output
problem.
E000013 is EACCES so you are running verify without write access to the
repository. That seems like a perfectly reasonable thing to do so we
should probably make the warning less intimidating.
It's very odd that Apache is reporting corruption but both the dump/load
and verify work without problem. Is the problem reproducible if you
restart Apache?
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2014-01-07 12:43:31 CET