We've just managed to lock our test repository again, and this time strace
doesn't do its magic.
Attached are two logs produced by strace, one for 'strace svnlook info
./TestRepos' and the other produced by 'strace svnadmin lstxns ./TestRepos'.
Any help would be *greatly* appreciated, since our repository is now locked
good and proper (and I can't reboot the server at the moment, since we have
other repositories currently in use).
Regards,
Stuart.
_____
From: Stuart Robertson [mailto:dogmatix@absolutesys.com]
Sent: 09 March 2004 10:09 AM
To: users@subversion.tigris.org
Subject: Wedged repository - why does strace unblock it? (was 'Stone-dead
repository')
The company I work for is currently investigating large-scale migration from
VSS to SVN. In the process of our investigations, we have developed custom
tools to migrate our old VSS repositories to SVN.
Yesterday, during test runs against our test repository, we once again ended
up completely locking the test repository. Previously (20 Feb), we had a
similar problem and I (incorrectly) assumed that the repository was
corrupted, since both svnadmin and svnlook would simply hang when trying to
access the repository. Posts to the svn users mailing list indicated that
the repository wasn't corrupted, but merely locked.
Back in the same situation again, I checked to ensure that there were no
hung processes that might have a lock on the repository. Checks on the
Apache logs (access_log and error_log) reveal that nothing unusual has
occurred as far as Apache is concerned. Each svn commit seems to start with
a MKACTIVITY, and ends with a corresponding DELETE entry in the lock. In
short, it doesn't appear as though anything went wrong on Apache's side.
After again checking for hung processes that might still be accessing the
repository, I tried 'svnadmin recover' and 'svnlook info' again, to no
avail. They simply hung, requiring a 'kill -9' to stop them.
Finally, I tried 'strace svnlook info ./TestRepos' to see what might be
causing the hang, and surprisingly when run via strace, 'svnlook info'
completes successfully. Subsequent runs of 'svnlook info' also complete
successfully. This is the same situation that occurred on the 20th Feb (see
the message-list archives at
http://subversion.tigris.org/servlets/ReadMsg?list=users
<http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=6173>
&msgNo=6173).
The vss migration-tool developers mentioned that they were browsing the
working copy whilst the migration process was in place when the hang
occurred. They have TortoiseSVN installed, and we are wondering if there
isn't some kind of interplay between the SVN command-line client (being used
to do the vss-to-svn migration) and TortoiseSVN.
If anyone has any ideas or suggestions for things to investigate I'd love to
hear them.
For reference sake, our server config is:
- RedHat Linux 9
- Kernel 2.4.20-8
- subversion-0.37.0-1
- subversion-server-0.37.0-1
- subversion-tools-0.37.0-1
- apr-0.9.5-0.2
- neon-0.24.4-1
- httpd-2.0.48-3
- 256MB RAM
I have purposely held off updating to svn 1.0 since posts to the mailing
list indicate that nothing of consequence has changed from 0.37 to 1.0.
Regards,
Stuart.
DISCLAIMER: This information is intended only for the person or entity to
which it is addressed and may contain private, confidential, proprietary
and/or privileged material and may be subject to confidentiality agreements.
Any review, retransmission, dissemination, or any other use of or taking of
any action in reliance upon this information, by persons or entities other
than the intended recipient, is prohibited. If you received this in error,
please contact the sender and delete the material from all storage media.
Absolute Systems (Pty) Ltd
Tel: +27 (0)11 784 0078
Fax: +27 (0)11 784 0148
Web: <http://www.absolutesys.com/> www.absolutesys.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 9 09:47:00 2004