On Tue, Jan 7, 2014 at 12:41 PM, Philip Martin wrote: > Mojca Miklavec 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?
Yes, there is still a problem after restarting Apache. Even though it works for me at the moment and I tried fetching from multiple locations and servers, other users are still experiencing the same problem. Logs on the server confirm that. (Unable to deliver content. [500, #0] + Could not write data to filter. [500, #175002]) Mojca