CentOS: Init scripts failing to start for some unknown reason

bootcentoschkconfiginit

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.

Best Answer

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

Related Solutions

Linux – Managing per-user rc.d init scripts

Your question basically includes the answer.... A script that'll iterate through a subdir of each users home, looking for executable scripts. Then it sudo -u user /export/home/user/scripts/scriptname.sh start. You'll have no control over what the scripts do, so you`ll need to trust your users.

Insist that they write their scripts to accept stop start restart as $1 param and that they shouldn't use any environment variables that have been set up in their .profile, .cshrc or .bashrc files. The script effectively needs to be standalone.

#!/usr/bin/bash

run_cmd {
cd /export/home
for HOMEDIR in *; do
  for SCRIPT in /export/home/$HOMEDIR/scripts/*;  do
     if [ -x $SCRIPT ]; then
       echo "$ACTION user $HOMEDIR's script $SCRIPT"
       sudo -u $HOMEDIR $SCRIPT $ACTION &
     fi
  done
done

}

case $1 in
    start) ACTION=start;
           run_cmd;;
    stop) ACTION=stop;
           run_cmd;;
    restart) ACTION=stop;
             run_cmd;
             sleep 60;
             ACTION=start;
             run_cmd;;
    *) echo "$1 not recognized as valid cmd";;
esac

exit 0

You'll need to tweak this for your environment, location of bash/homedirs etc.

The “best” `start on` value for an Upstart (init) scripts

You should probably spend some time looking at some documentation (generally good advice for anything) as it really depends upon your service and what it's requirements are. There is no generic 'best' only that which meets the requirements of your service.

The difference in whether to use the more generic 'runlevel' or the more explicit local-filesystems(7) and net-device-up events should be guided by your job's behaviour. If your service will come up without a valid network interface (for instance, it binds to 0.0.0.0, or uses setsockopt(2) SO_FREEBIND), then the runlevel event is preferable, as your service will start a bit earlier and start in parallel with other services.

However if your service requires that a non-loopback interface is configured for some reason (i.e., it will not start without broadcasting capabilities), then explicitly saying "once a non loopback device has come up" can help...

Related Topic