CVS server problem

[DrDoc]

Ok, I have a CVS server set up on one of my machines. Everything works great, until I reboot the machine. After the machine is rebooted I always have to run

/etc/init.d/xinetd reload

and/or

/etc/rc.d/init.d/xinetd reload

(one or the other... sometimes both). Once I do that, CVS works great until next reboot, after which I have to repeat the above procedure.

I've quadruple checked the configuration. Firewall is open on port 2401. There are no meta characters (and such) in xinetd.conf. Permissions are properly set for CVS. All it takes is to reload the xinetd configuration, and it will work.

Any ideas? :(

[MattyMoose]

Is xinetd loading on startup? It may be that the "reload" starts xinetd if it's not already started.

Next reboot, do a "ps -aux¦grep xinetd", see if it's running.

If it isn't, then it's a setting somewhere to tell the system to start xinetd.

If it is, then maybe xinetd is using another config file, possibly a default one when it starts up, but the proper one when it reloads?

[DrDoc]

Yes, xinetd is running on startup...
And, I don't know why it would load a different config file on startup, since I've modified the default one...
Nevertheless, I searched the system to see if there was another xinetd.conf anywhere, but there wasn't.

I'm stumped :(

[encyclo]

When booting, what loads after xinetd, if anything? There could be something which follows in the boot sequence which is affecting things.

If it is difficult to identify, you may have to reload everything in init.d one at a time, and see if the CVS server works after reloading each other daemon. If it stops working after reloading a particular init.d script, the problem must lie within that script.

[bakedjake]

Doc, can we have the contents of xinetd.conf?

[DrDoc]

xinetd.conf

# 
# Simple configuration file for xinetd 
# 
# Some defaults, and include /etc/xinetd.d/ 
defaults 
{ 
  instances    = 60 
  log_type    = SYSLOG authpriv 
  log_on_success   = HOST PID 
  log_on_failure   = HOST 
  cps      = 25 30 
} 
includedir /etc/xinetd.d 
cvspserver stream tcp nowait root /usr/bin/cvs cvs --allow-root=/repository pserver 

[MattyMoose]

I thought I'd mention also that it may be easier/safer (due to a couple of semi-recent pserver vulnerabilities) to use cvs over ssh.

that way you don't need to open up the CVS port, or have the pserver service. People would just have an account (and you can create an anonymous account) to co and ci.

[DrDoc]

Yeah, I've been thinking about cvs over ssh... but that's not applicable to this situation, since I'm only using cvs on an internal network.

It still isn't working :( And, unfortunately I had to reboot the server again yesterday. :(

[jollymcfats]

When you rebooted, were there any xinetd related messages in the syslog?

[DrDoc]

No messages...

[jollymcfats]

When you reboot, how many xinetd services are actually listening? Is pserver one of them? You can run 'netstat -ltu' or your Unix's equiv.

Also, let's back up a bit- what's wrong with CVS when you reboot? Connection refused? Something else?

[DrDoc]

No, pserver is not one of them when I reboot (and shouldn't be)
Basically, the port is open, but xinetd is unable to start cvs upon incoming request (for some reason). So I get all sorts of weird results: connection refused, end of file, etc.

[jollymcfats]

You might try changing the invocation config. The final entry in the xinetd FAQ (on the official xinetd site) has an alternate config for cvspserver.