Project: | The Hive project |
Component: | Miscellaneous |
Category: | bug report |
Priority: | critical |
Assigned: | john |
Status: | fixed |
Today I noticed that I cannot reach any of the subversion repositories at oehive anymore. I have tried url's like "svn://oehive.org/prolint/trunk" from TortoiseSVN from different computers, for different repo's, with and without firewalls but allways get a message like connection refused.
No idea how long this situation already exists, because I have been horribly passive for a long while. May perhaps be caused by Westhost VM conversions??
Comments
#1
Hi Jurjen, it's more likely that I broke something. I've been trying to get git and gitweb installed and running. Most of what I've done so far should not have affected anything running on oehive. I think the most likely culprit is that I installed a newer version of libcurl. Here's what I've done so far:
- Created sub-domain git.oehive.org.
- Installed curl/libcurl. (WestHost had libcurl, but no include headers for compiling against)
- Installed git. (Installed into default directory: ~)
- Copied (build-dir)/gitweb/git* to /var/www/git.oehive.org/cgi-bin.
- Created and edited /var/www/cgi-bin/gitweb_config.perl.
I will start investigating right away. I sure don't want SVN out of commission!
I will start by bouncing the machine. If that doesn't work I'll check the logs, and upgrade SVN (it's due anyway, and maybe building against the latest libcurl will help).
#2
Something restarted the WestHost virtual machine at midnight, and svnserve didn't restart at that point. I can launch svnserve manually, but it's not getting launched at boot time. It's supposed to be started by xinetd, so maybe something is wrong with xinetd. Still investigating...
#3
It's working now, but I don't know why. I fiddled a bit with /etc/xinetd.conf, but I don't think any of the changes I made should have fixed anything. I changed it to write to a log file rather than use 'syslog', since syslog is not installed on WestHost. But, it was working before, so I doubt that's what got it working again.
I'll mark this issue as 'fixed' for now. If we have any more trouble with xinetd then maybe I should just drop it and create entries in /etc/init.d instead.
#4
thumbs up! thanks