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
Received on 2014-01-07 16:33:37 CET