Managing Initscripts with Red Hat's chkconfig

A simple but quite useful addition to your administration command vocabulary.
Adding a chkconfig Entry

So far, so good. We've seen how to view, modify and delete services using chkconfig. It's time to add a new service. Take the script named oracle (see Listing 1).

Listing 1. Oracle Script

Using this script, Oracle 8 can be started with the “start” argument and terminated with the “stop” argument. This meets the minimum requirements of an initscript that can be used in conjunction with the launch script /etc/rc.d/rc.

Place the script in /etc/rc.d/init.d and run (as root)

chmod +x /etc/rc.d/init.d/oracle

to make the script executable. If you are concerned about normal users seeing the script, you could try more restrictive file permissions, as long as the script is executable by root as a standalone script.

Notice the two comments lines in the script:

#chkconfig: 2345 80 05
#description: Oracle 8 Server

These lines are needed by chkconfig to determine how to establish the initial runlevels to add the service as well as set the priority for the start-and-stop script execution order. These lines denote the script will start Oracle 8 server for the runlevels 2, 3, 4 and 5. In addition, the start priority will be set to 80 while the stop priority will be 05.

Now that the script is in place with the appropriate execute permissions and the required chkconfig comments are in place, we can add the initscript to the chkconfig configuration by typing, as root, chkconfig --add oracle.

Using chkconfig's query feature, we can verify our addition:

[root]# chkconfig --list | grep oracle
oracle        0:off     1:off   2:on   3:on   4:on   5:on  6:off

Also, we can type our standard find command to see how chkconfig set up the symbolic links:

[root]# find /etc/rc.d -name '*oracle' -print
As requested, the names of the kill links contain the priority 05 while the start links contain 80. If we need to adjust the priorities, (e.g., our stop priority needs to be 03), simply modify the chkconfig comment lines in the initscript for oracle and run the reset command, as shown below. The resulting symbolic links will be renamed accordingly:
[root]# chkconfig oracle reset
[root]# find /etc/rc.d -name '*oracle' -print

Enhancements in Red Hat 7

As many of you already know, inetd was replaced by xinetd in Red Hat 7. In addition, chkconfig functionality has been extended to manage some of the functionality of xinetd's Internet services. Sample output is shown below:

[root]# chkconfig --list
xinetd based services:
      finger:  on
      linuxconf-web:  off
      rexec:  off
      rlogin:  off
      rsh:  off
      ntalk:  off
      talk:  off
      telnet:  on
      tftp:  off
      wu-ftpd:   on

To disable a xinetd feature, perhaps finger, you could type [root]# chkconfig finger off.

Pretty neat, huh? However, there is one “gotcha”. When the configuration is changed, the xinetd is signaled automatically to reload the new configuration with the command /etc/init.d/xinetd reload, that is executed by chkconfig. This script performs a kill with the SIGUSR2 signal which instructs xinetd to perform a hard reconfiguration.

What does that mean? Well, when I tested it, the active sessions of services offered through xinetd (i.e., Telnet, FTP, etc.) were immediately terminated. That might not be a problem for you, assuming you can plan the best time to disable/enable xinetd services on your system. As an alternative, you can modify the /etc/init.d/xinetd script so that the reload option sends a SIGUSR1 signal, which is a soft reconfiguration. This will restart the services without terminating existing connections.

Adding xinetd services for chkconfig management is as simple as adding an xinetd service file into the /etc/xinetd.d directory. The chkconfig utility will automatically pick it up and make it available for management through the chkconfig utility. Neat!



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.