In UNIX if a kill -9 by root doesn't kill a process in a reasonable
amount of time, then the process is most likely in kernel-space doing
device IO and there is something blocking that, such as a physical
device with problems. Signals (even KILL=9) cannot be received while in
a device driver. I would check for IO errors.
Stuart Robertson wrote:
> Further to my last post, I now have two 'svnlook info' processes that even
> root cannot kill.
>
> Running ps aux shows the following two processes:
>
>
>
> svn 6038 0.0 0.8 9092 2224 pts/1 T 10:29 0:00 svnlook
> info ./TestRepos/
>
> svn 6041 0.0 0.8 9092 2224 pts/1 T 10:30 0:00 svnlook
> info ./TestRepos/
>
>
>
> I can't claim to be a Unix guru, but it's the first time I haven't been able
> to kill a process as root.
>
>
>
> Anyone have any pointers/ideas?
>
>
>
> 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 19:13:53 2004