Managing Initscripts with Red Hat's chkconfig

The chkconfig binary resides in /sbin with default permissions that allow any user to execute it, although the user without root privileges can only view the current chkconfig configuration. So type

[root]# chkconfig --list | grep on

A partial listing of the output would look similar to the following:

amd 0:off 1:off 2:off 3:off 4:on 5:on 6:off
apmd 0:off 1:off 2:on 3:off 4:on 5:off 6:off
arpwatch 0:off 1:off 2:off 3:off 4:off 5:off 6:off
atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off
autofs 0:off 1:off 2:off 3:off 4:off 5:off 6:off
named 0:off 1:off 2:off 3:off 4:off 5:off 6:off
bootparamd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
keytable 0:off 1:off 2:on 3:on 4:on 5:on 6:off
crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off
syslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off
netfs 0:off 1:off 2:off 3:on 4:on 5:on 6:off
network 0:off 1:off 2:on 3:on 4:on 5:on 6:off

On each line of output, the first field represents the name of an initscript in /etc/rc.d/init.d. The remaining fields correspond to the runlevels 0-6 along with the status of the script when entering that runlevel. For example, crond would be launched when entering the runlevels 2, 3, 4 and 5 and stopped when entering the runlevels 0, 1 and 6. We can confirm that these settings are true with the find command to search for all files in /etc/rc.d that end with crond:

[root]# find /etc/rc.d -name '*crond' -print
/etc/rc.d/init.d/crond
/etc/rc.d/rc0.d/K60crond
/etc/rc.d/rc1.d/K60crond
/etc/rc.d/rc2.d/S40crond
/etc/rc.d/rc3.d/S40crond
/etc/rc.d/rc4.d/S40crond
/etc/rc.d/rc5.d/S40crond
/etc/rc.d/rc6.d/K60crond

Notice for each “off” section reported by chkconfig (0, 1, 6), a kill script is in place and for each “on” section reported (2, 3, 4, 5), a start script exists. Next, execute a different find command to determine the type of each file found:

[root]# find /etc/rc.d -name '*crond' -exec file {} \;
/etc/rc.d/init.d/crond: Bourne shell script text
/etc/rc.d/rc0.d/K60crond: symbolic link to
  ../init.d/crond
/etc/rc.d/rc1.d/K60crond: symbolic link to
  ../init.d/crond
/etc/rc.d/rc2.d/S40crond: symbolic link to
  ../init.d/crond
/etc/rc.d/rc3.d/S40crond: symbolic link to
  ../init.d/crond
/etc/rc.d/rc4.d/S40crond: symbolic link to
  ../init.d/crond
/etc/rc.d/rc5.d/S40crond: symbolic link to
  ../init.d/crond
/etc/rc.d/rc6.d/K60crond: symbolic link to
  ../init.d/crond

This reveals that crond found inside init.d is a shell script and all remaining files found are symbolic links to the crond script.

Modifying a chkconfig entry is almost as easy as listing the existing configuration. The form is:

chkconfig [--level <levels>] <name> <on|off|reset>

For example, if we decide to disable crond for runlevel 2, the chkconfig --level 2 crond off command (executed by root) would turn off crond for the runlevel of 2. Running chkconfig --list will confirm that crond's configuration has been modified. Further, the find command below reveals that a kill script has replaced the start script in the rc2.d directory:

[root]# find /etc/rc.d -name '*crond' -print
/etc/rc.d/init.d/crond
/etc/rc.d/rc0.d/K60crond
/etc/rc.d/rc1.d/K60crond
/etc/rc.d/rc2.d/K60crond
/etc/rc.d/rc3.d/S40crond
/etc/rc.d/rc4.d/S40crond
/etc/rc.d/rc5.d/S40crond
/etc/rc.d/rc6.d/K60crond

Keep in mind that chkconfig does not automatically disable or enable a service immediately. It simply changes the symbolic links. The superuser could disable the crond service immediately with the command /etc/rc.d/init.d/crond stop. Finally, you can enable/disable a command for multiple runlevels with one chkconfig command. For example entering

chkconfig --levels 2345 crond on

would set up crond to be started for runlevels 2, 3, 4 and 5.

At times, removing a service altogether may be in order. Take sendmail, for example. On client machines where incoming mail for local accounts is not required, running sendmail as a dæmon may not be necessary. In this case, I find disabling sendmail desirable since it reduces potential security risks. To remove sendmail from chkconfig, type

chkconfig --del sendmail

Below, our find command shows no symbolic links in place, while the initscript for sendmail remains:

[root]# find /etc/rc.d -name '*sendmail' -print
/etc/rc.d/init.d/sendmail

This is perfect in my opinion. The script is left in case sendmail needs to be re-established as a service, but all symbolic links are gone. While we could have disabled sendmail for all runlevels, this would have placed kill scripts in each of the rc*.d subdirectories, an unnecessary task since sendmail was never launched during the initialization phase. However, I have seen situations when the system administrator would manually start a service on certain occasions. Having the kill scripts in place for that service ensures a cleanly killed service. So, you make the call.