Managing Initscripts with Red Hat's chkconfig

A simple but quite useful addition to your administration command vocabulary.
Viewing chkconfig Entries

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
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
/etc/rc.d/rc1.d/K60crond: symbolic link to
/etc/rc.d/rc2.d/S40crond: symbolic link to
/etc/rc.d/rc3.d/S40crond: symbolic link to
/etc/rc.d/rc4.d/S40crond: symbolic link to
/etc/rc.d/rc5.d/S40crond: symbolic link to
/etc/rc.d/rc6.d/K60crond: symbolic link to
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 chkconfig Entries

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

Removing an Entry

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



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Oracle shutdown not working

Thomas Gutzmann's picture


thanks for this article.

One addition: Oracle doesn't shutdown automatically in RHEL5 if /var/lock/subsys/ isn't considered.

Please refer to .



Oops... the most important

Thomas Gutzmann's picture

Oops... the most important information was truncated:

Refer to

Your script needs to touch a /var/lock/subsys/oracle file upon successful startup, and remove it on a successful stop. In a shutdown, services are stopped that have a lock file in /var/lock/subsys.

Here's what I've added to my script:


echo -n $"Starting Oracle: "
/bin/su - oracle -c "dbstart \$ORACLE_HOME" &
/bin/su - oracle -c "opmnctl startall" &
/bin/su - oracle -c "emctl start dbconsole" &
/bin/su - oracle -c "export ORACLE_HOME=$ORACLE_HOME/oc4j; $ORACLE_HOME/bin/oc4j -start &"
touch /var/lock/subsys/oracle
exit 4

echo -n $"Stopping Oracle: "
/bin/su - oracle -c "touch \$ORACLE_HOME\init_stop"
/bin/su - oracle -c "opmnctl shutdown" &
/bin/su - oracle -c "emctl stop dbconsole"
/bin/su - oracle -c "lsnrctl stop"
/bin/su - oracle -c "dbshut \$ORACLE_HOME"
rm /var/lock/subsys/oracle
exit 0

Hope it's readable now, otherwise contact me at


Sandeep's picture

Super Article....
Helped a lot Jimmy.




Sunil's picture

Perfect writeup. Very useful

Thank you

Mike Lerley's picture

Thank you! Oldie but goodie. Have been wanting to decipher this for years.


Sr Perez's picture

I found many references to "add these comments at the begining of the script", but no one seemed to have any idea what they meant. Your article gave me everything I needed to know.


very interesting and useful

marco66's picture

just want to thank for the article. I was googling for this topics, and when i found it I saved immediately a copy in my how-to-do


excellent article

Anonymous's picture

i just wanted to thank you for this great article !!

these line are magical:
#chkconfig: 2345 80 05

Managing Initscripts with Red Hat's chkconfig

Richard Armstrong-Finnerty's picture

This article was EXTREMELY useful! Thanks for writing it!

good job!!

Roll's picture

neatly explained! but im a bit confused with the start and stop priority.. what are available values for those and how to choose the right one for my own script?

start priority

Andy Goldschmidt's picture

The priority is a number from 0 upwards.
It simply determines the order in which services start. Low numbers = start before high numbers.

e.g. you want your network to be up before start apache server.

S10network -> ../init.d/network
S85httpd -> ../init.d/httpd

The list above - network starts first.

At shutdown the reverse happens. stop httpd first before stopping network.
K90network -> ../init.d/network
K15httpd -> ../init.d/httpd

Service starts as daemon user

Anonymous's picture

Excellent article. Once the service is started, it looks to be running as the daemon user. How would you start a service as a different user other than daemon? Thanks.

Most common way is by command line switch

Anonymous's picture

Many daemons are started with a specific user & group by command line switches, for example you might see this one if you are running mySQL:

/usr/bin/mysqld_safe --user=mysql

Some have configuration files that specify the user/group, like for example often has this in it:


(Note the user "mail" has uidNumber eight, the group "mail" has gidNumber twelve on a typical Red Hat system)

Stuff that is run out of xinetd can use xinetd's inherent capability to manage users with appropriate configuration lines in /etc/xinetd.d - type "man xinetd.conf" on a typical Red Hat system and look at the user and group options.

Primitive daemons that don't have the ability to change their user or drop capabilities can still be run as a specific user with appropriate scripting in the init script; Red Hat supplies a tool for this in RHEL5 (/sbin/runuser) but in earlier versions you'll need to understand how to use and script the "su" command.

But it all boils down to this: the init script (for standalone daemons) or a file in the xinetd.d folder (for daemons invoked on the fly by the xinetd superdaemon) can control the user and group of a system daemon. If a daemon has a user/group option in its configuration file, you can use that, but the init script could override it.