There is a command in Linux that allows you to control what services start when your server starts, and in what order, and even in what order they stop when you shutdown or reboot your server. This command is called chkconfig and I am going to explain what it is, what it does and what it all means to you, in this article.

Before I get into the chkconfig command itself, let me start by giving you a little background to help things make more sense. A great deal of Linux and UNIX systems today are derivatives of what was originally known as “System V” or commonly abbreviated SysV, in the design of how system startup and shutdown is controlled. Some examples would be Solaris UNIX, and Linux to name a couple that are very popular. This design is based around what is called runlevels. You can think of a runlevel as a state that the system is in, that state would be all of the processes or services that are running. Two common examples from Linux are runlevel 3, and runlevel 5, and are the two most commonly used runlevels upon startup. You see, in Linux for example, you set what runlevel to go into on startup in a file, usually called the inittab. If you were to set runlevel 3 for example, the system would come up and be completely functional, with networking, but would have no GUI (Graphical User Interface). In other words, XWindows wouldn’t start. In contrast, if you set runlevel 5, it would come up and start the GUI.

For each service you want to manage (control startup and shutdown of automatically), there should be a corresponding script, called an init script (short for initialization script) that resides in the /etc/init.d directory (the location of this directory varies, but usually there is a symbolic link from /etc/init.d to where ever the location is). This directory holds all of the scripts that start and stop services on your system. Typically they are used by executing the script, but with an operand that tells it what to do, like start, stop or restart. So, to start sendmail for example, you would run “sendmail start”. Now, these init scripts work to start and stop all of the services in different runlevels. How? Good question! There are links from runlevel directories that link to the init scripts. So, for our runlevel 3 earlier, on a RedHat Linux system there is a directory called /etc/rc.d/rc3.d that has symbolic links to the init scripts. If you look at this directory, you will see an interesting naming convention. For each service, and therefore each link, the name tells the system what to do. Clever, huh? You see, each link starts with a letter, an S for start, or a K for kill. Next we have a number that denotes when the service should start, so you can actually control the order in which your services startup! Then you have the name of the service.

So, let us go back to our sendmail example. If we wanted sendmail to start automatically in runlevel 3, and start after everything else, we would name the symbolic link S99sendmail in /etc/rc.d/rc3.d and it would link to the init script /etc/init.d/sendmail. The S tells the system to start it, it’s in rc3.d so that tells the system that this applies when the system is entering runlevel 3, and the number tells it to start all other services before this one that have a number lower than 99. In effect, when the system enters runlevel 3, it will process each link in in that directory in numerical order. If the script starts with an S, it’s the same as manually running the init script with a start operand, and of course K would equate to stop. It’s pretty simple really, as the server moves through runlevels, these symbolic links control what starts when. In addition, because they link to a common set of init scripts, you only have one script to modify whenever a change needs to be made. There is a lot more to know about System V, and how systems startup and shutdown, but for the purposes of this article, it’s not necessary to go into all of the gory details. I am simply trying to give a broad overview for the purposes of explaining chkconfig.

Having said all that, the tricky part now is to manage all those links, which can be a pain if you are trying to manually create, remove or change all those links! Thankfully, you don’t have to, and this is where we get into chkconfig (finally, I know), because the chkconfig tool can manage all of these links for you.

Let’s start with the man pages, here is a paraphrased summary of chkconfig:

chkconfig – updates and queries runlevel information for system services

SYNOPSIS

chkconfig –list (name)
chkconfig –add name
chkconfig –del name
chkconfig (–level levels) name <on|off|reset>
chkconfig (–level levels) name

Each service which should be manageable by chkconfig needs two or more commented lines added to its init.d script. The first line tells chkconfig what runlevels the service should be started in by default, as well as the start and stop priority levels. If the service should not, by default, be started in any runlevels, a – should be used in place of the runlevels list. The second line contains a description for the service, and may be extended across multiple lines with backslash continuation.

For example, random.init has these three lines:

# chkconfig: 2345 20 80
# description: Saves and restores system entropy pool for \
# higher quality random number generation.

This says that the random script should be started in levels 2, 3, 4, and 5, that its start priority should be 20, and that its stop priority should be 80. You should be able to figure out what the description says; the \ causes the line to be continued. The extra space in front of the line is ignored.

As you can see, chkconfig is your friend. By simply adding two lines, comments of all things, to the top of your init script, you allow chkconfig to take control of all that linking for you. So with one command, you can tell it to start sendmail in runlevels 3 and 5, but make sure it is stopped in all the others.

One extra point I want to make here is about stopping services. There is a reason that you are able to setup links to stop services, as well as start them. The main one being that you can gracefully stop a service, therefore ensuring the integrity of your data and files related to that service, rather than just having it crash as the machine shuts down or reboots. That means that it’s important to setup links to stop services when you setup the links to start them. I can’t tell you how many admins I have seen or worked with that are all about setting up services to start, but never set them up to stop. I for one don’t want my data hosed, or my server to get stuck on a reboot because some service hangs or something.

I hope this article on chkconfig is useful to you!