Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm running CentOS 6.2 - I've just migrated some applications over to a failover server, and copied their init scripts into /etc/init.d.

I've made them executable, added them to chkconfig, with chkconfig -add, set their levels, made sure they're residing in /etc/rc.d/ - made sure I can execute them from rc2.d etc. The permissions are the same on both servers. They're also running in the same order as on the primary server

Yet on reboot they don't start. Any ideas?

The offenders are these:

jetty           0:off   1:off   2:on    3:on    4:on    5:on    6:off
smart           0:off   1:off   2:on    3:on    4:on    5:on    6:off

/etc/init.d:
-rwxr-xr-x. 1 root root 14456 Mar 13 20:21 jetty
-rwxrwxrwx. 1 root root  5829 Mar 29 09:58 smart

/etc/rc.d/rc3.d
lrwxrwxrwx. 1 root root 15 Mar 29 19:21 S99jetty -> ../init.d/jetty
lrwxrwxrwx. 1 root root 11 Mar 26 17:12 S99local -> ../rc.local
lrwxrwxrwx. 1 root root 15 Mar 29 19:21 S99smart -> ../init.d/smart

I've checked, and I'm in run level 3. I've checked their logs, and there's no indication that that they've been started. I can start them manually easily - and other services are starting normally.

I'm completely out of ideas really.

share|improve this question
    
is there anything unusual in your /etc/inittab or /etc/init/rc.conf? –  Kenny Rasschaert Mar 29 '12 at 16:58
    
They're the same on both systems, which are both relatively recent installations. –  user705142 Mar 29 '12 at 20:49

3 Answers 3

up vote 1 down vote accepted

I think I may have solved it.

For some reason the init scripts weren't being copied to /etc/rc.d/init.d ! I've made symlinks there, and now chkconfig is picking them up, and most of them are now starting on boot..

share|improve this answer
1  
That's odd in itself: /etc/init.d is a symlink to /etc/rc.d/init.d on my system. –  cjc Mar 30 '12 at 2:01
    
It is on my initial system as well. Something went wrong here. Anyway, it's all up and running now. –  user705142 Apr 1 '12 at 10:17

I am a user of CentOS 6.5 and Jetty 9.1.0.v20131115. I ran into the same symptoms that you are describing.

I was able to fix my issue by updating jetty.sh, respectively /etc/init.d/jetty, respectively /etc/rc.d/init.d/jetty.

In this script, in the NAME definition, change + to *, i.e. change
NAME=$(echo $(basename $0) | sed -e 's/^[SK][0-9]+//' -e 's/\.sh$//')
to
NAME=$(echo $(basename $0) | sed -e 's/^[SK][0-9]*//' -e 's/\.sh$//')

The jetty.sh script used to have a chkconfig-related bug. This bug got fixed in a commit.

Background: In the buggy version, the NAME environment variable gets set to jetty99, 99 coming from a chkconfig configuration.
The script is usually named jetty, therefore the buggy version will look for a configuration file named /etc/default/jetty99 instead of the correct /etc/default/jetty.

share|improve this answer

Can you check the status using the ntsysv command? Make sure the daemons you need are selected.

Do the daemons start properly with /sbin/service daemonname start?

share|improve this answer
    
They start fine with service deamon start - and they're selected in ntsysv as well. –  user705142 Mar 29 '12 at 7:02
    
More information - I've removed the scripts via chkconfig --del and added them again. Now chkconfig won't add them at all. AFter 'chkconfig --add smart', I 'chckconfig --list smart' and I get "service smart supports chkconfig, but is not referenced in any runlevel (run 'chkconfig --add smart')". –  user705142 Mar 29 '12 at 21:01
    
I've also rechecked their headers - and there doesn't seem to be anything amiss –  user705142 Mar 29 '12 at 23:07

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.