3

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.

2
  • is there anything unusual in your /etc/inittab or /etc/init/rc.conf? Mar 29, 2012 at 16:58
  • They're the same on both systems, which are both relatively recent installations.
    – user705142
    Mar 29, 2012 at 20:49

3 Answers 3

1

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..

2
  • 1
    That's odd in itself: /etc/init.d is a symlink to /etc/rc.d/init.d on my system.
    – cjc
    Mar 30, 2012 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, 2012 at 10:17
1

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.

0

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?

3
  • They start fine with service deamon start - and they're selected in ntsysv as well.
    – user705142
    Mar 29, 2012 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, 2012 at 21:01
  • I've also rechecked their headers - and there doesn't seem to be anything amiss
    – user705142
    Mar 29, 2012 at 23:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .