Chkconfig <service name> on

[deaner]

Ok,

So I have Citrix CloudPlatform Management and NFS running on Centos 6.3 No issues with the install except it does not matter for the life of me, why when setting the Cloudstack-Management service to start at boot - its always dead?

Second.. some pointers on troubleshooting the service as a whole - it likes to stop randomly.

Thanks.

 

[mv2devnull]

1. You should update. 6.3 is not the latest 6.x any more.

2. Does that service have any kind of debugging options? Verbosity setting? /var/log/messages?

 

[Scarpozzi]

1. You should update. 6.3 is not the latest 6.x any more.

2. Does that service have any kind of debugging options? Verbosity setting? /var/log/messages?

If you install 6.3, as long as the packages are compatible with the applications you're running and you don't need a newer version of something, they'll get all the security patches... I don't see a need to upgrade to 6.5.

I don't know much about that particular app, but there's a chance that it's starting too soon or in the wrong runlevel. I've not played with Cloudstack-Management, but what you could do is go to the startup script and throw a delay in it to see if that helps.

Definitely check /var/log/cloud/management and look at the management-server.log

I believe that's a tomcat app, so make sure the startup script in /etc/init.d/ is citing the correct install location and settings. I typically have all of my tomcat apps set to manually start simply because they require database connections and have other dependencies that may keep them from starting up. For that reason, I typically script my own startup/shutdown scripts to control all systems required for a particular app to function.

 

[deaner]

If you install 6.3, as long as the packages are compatible with the applications you're running and you don't need a newer version of something, they'll get all the security patches... I don't see a need to upgrade to 6.5.

I don't know much about that particular app, but there's a chance that it's starting too soon or in the wrong runlevel. I've not played with Cloudstack-Management, but what you could do is go to the startup script and throw a delay in it to see if that helps.

Definitely check /var/log/cloud/management and look at the management-server.log

I believe that's a tomcat app, so make sure the startup script in /etc/init.d/ is citing the correct install location and settings. I typically have all of my tomcat apps set to manually start simply because they require database connections and have other dependencies that may keep them from starting up. For that reason, I typically script my own startup/shutdown scripts to control all systems required for a particular app to function.

Appreciate the direction - good points here, thank you.

 

[deaner]

1. You should update. 6.3 is not the latest 6.x any more.

2. Does that service have any kind of debugging options? Verbosity setting? /var/log/messages?

Yes, I have been oggleing through some logs but nothing definitive as of yet -

 

[mv2devnull]

they'll get all the security patches... I don't see a need to upgrade to 6.5.

6.5 is the security patch for 6.3. If you somehow have 6.3 and do

yum update

The yum will fetch from repository packages for 6 and for a while still they are 6.5 packages. When 6.6 is released, there will be no more patches for 6.5 (or any previous version). The only way to avoid this default behaviour is to explicitly lock to (archived) older repository branches.

 

[Red Squirrel]

I've seen this happen for whatever reason a service wont start properly at start even if it's set.

I usually end up just putting service [nnn] start in /etc/rc.local. Kind of dirty but it works.

Has anyone played with CentOS 7 yet? I'm not sure if I'm a fan of it, they changed quite a lot of stuff. They seem to want to depricate the service and chkconfig commands, among other things and replace with a new command called systemctl.

 

[KillerBee]

here's some info on the new way of doing things

Overview of systemd for RHEL 7
https://access.redhat.com/articles/754933