View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000672||Subversion for OS/2 & eCS||Bug||public||2018-01-20 14:01||2020-08-24 13:23|
|Status||closed||Resolution||unable to reproduce|
|Target Version||Fixed in Version|
|Summary||0000672: svnserve.exe 1.7.21 is unable to serve requests when configured for logging and log cannot be written|
|Description||Due to an apparent crash during an SVN transaction, svnserve's log file (located on an HPFS volume) apparently became corrupted (and could not be appended). Following the reboot and subsequent start of svnserve.exe, connections could be established via svn://, but no data was returned.|
|Additional Information||The initial thought was that there was a firewall issue or something blocking the transmission. The client could be killed with Ctrl-C, reporting that the server could not be contacted (E175002: Unable to connect to repository at URL 'svn://<server>/project').|
On the server side, making a connection reported a socket established. After Ctrl-C on the client side, the socket went to CLOSE_WAIT, and was closed in an orderly fashion.
Connections via mod_dav_svn continued to work as expected, indicating that there was no corruption of the project files.
Ultimately, moving svnserve.exe out of the Startup folder and rebooting (svnserve.exe could not be killed in this state, and the log file was locked open, disallowing all attempts at reading) allowed us to rename the existing log file and examine it. Starting svnserve at that point, allowing it to create a fresh log file, worked as expected.
svnserve.exe startup parameters:
--foreground -d --memory-cache-size 384 --cache-txdeltas yes --cache-fulltexts yes -r ..\data --log-file=c:\var\log\svnserve.log
The workaround is to rotate the log at each system start, before svnserve.exe loads, however, the real issue is that failure to log should not equal failure to serve requests. This may be an upstream issue, however.
|Tags||No tags attached.|
||Hey @Lewis can you remind me which build of subversion this is - built with apr-os2 or apr-posix?|
This is from:
The readme.os2 was not updated in this package from:
8-10-15 2:31 1,046 124 readme.os2
svnserve.exe --version doesn't give me build level info. The best reference I have for you is our email thread (just prior to the date of the zip) entitled "update requests" wherein I asked you for a refreshed svn with an Apache module. Your comment at the time was "Probably better to spend time on fixing Apr than updating subversion."
Hopefully, your build info will point you in the right direction to match up the code.
7-07-16 5:23 1,388,628 124 svnserve.exe
md5sum: 328a46a6c33bc74498a33d7b755345bf *svnserve.exe
||Can we confirm if this is still an issue with 1.14.x - it doesn't make sense to chase issues with 1.7.x|
I've tried to reproduce the issue, and I cannot. It's possible that with a corrupted logfile might cause this again, but I even copied a binary file into place and svnserve dutifully appended fresh logging data to the binary. If the log file is flagged RO, svnserve.exe refuses to start, as expected:
svnserve: E720005: Can't open file 'C:/var/log/svnserve.log': SYS0005: Access is denied.
However, the client-side stall is just not happening with 1.14.
|2018-01-20 14:01||LewisR||New Issue|
|2018-01-20 14:01||LewisR||Status||new => assigned|
|2018-01-20 14:01||LewisR||Assigned To||=> psmedley|
|2018-01-20 17:27||psmedley||Note Added: 0003168|
|2018-01-21 00:22||LewisR||Note Added: 0003169|
|2018-01-21 00:24||LewisR||Note Edited: 0003169||View Revisions|
|2020-08-24 12:33||psmedley||Status||assigned => feedback|
|2020-08-24 12:33||psmedley||Note Added: 0003508|
|2020-08-24 13:17||LewisR||Status||feedback => resolved|
|2020-08-24 13:17||LewisR||Resolution||open => unable to reproduce|
|2020-08-24 13:17||LewisR||Note Added: 0003513|
|2020-08-24 13:23||psmedley||Status||resolved => closed|