Managing Initscripts with Red Hat's chkconfig
I love discovering new UNIX commands, especially those with a system administration flavor. When I learned Red Hat distributed the chkconfig utility, it brought back fond memories of chkconfig under IRIX, a UNIX variant from Silicon Graphics, Inc. IRIX's chkconfig was designed to enable/disable services for automatic launch during system initialization without editing, renaming or moving initscripts in /etc.
Similarly, Red Hat designed chkconfig to help manage services launched during system initialization. But, after perusing the man page and doing some tests, I soon found that Red Hat extended chkconfig with finer control of system startup/shutdown tasks by managing the symbolic links to initscripts. It's a real time-saver!
When your Linux box boots, the first process that shows up is init. If you haven't seen init before, take a moment to type ps -ef | grep init to see the PID of init. In short, the init performs tasks that are outlined in /etc/inittab.
Some tasks outlined in /etc/inittab will be launched soon after init, while others are simply set up. For example, the default Red Hat /etc/inittab sets up a trap for the key sequence Ctrl-Alt-Delete. When these keys are simultaneously pressed at a console prompt (not xdm), the shutdown command is performed. At boot time, init sets up this feature based on configuration options in /etc/inittab, but execution is postponed until the key sequence occurs.
The format of inittab allows for comment lines beginning with a “#” symbol while normal entries are “:” delimited. They follow the pattern id:runlevel:action:process where id represents a user-defined and unique identifier, runlevel can be a combination of the numbers 0-6 or just left blank, action comes from a keyword that describes how init should treat the process, and process is the command to execute.
Descriptions of various keywords for the action field can typically be found in the man pages for inittab. Common keywords across most, if not all, UNIX platforms include:
initdefault—defines the runlevel to enter once the system has booted.
wait—a process that will be executed once (when the runlevel is entered). The init process will wait for this process to terminate.
boot—defines a process that is executed at boot time.
bootwait—similar to boot but init waits for the process to terminate before moving on.
sysinit—defines a process that is executed at boot time before any boot or bootwait inittab entries.
The runlevel field designates system state. For example, a runlevel of 0 corresponds to a halted system while a runlevel of 6 corresponds to a system reboot. Unfortunately, all Linux distributions do not follow the same definition for runlevels. Under Red Hat, the following defaults are supported:
0. System halt 1. Single-user mode 2. Multiuser, without NFS 3. Complete multiuser mode 4. User defined 5. X11 (XDM login) 6. Reboot
For each runlevel, there is a corresponding directory in /etc/rc.d. For a runlevel of 5, the directory /etc/rc.d/rc5.d exists and contains files related to tasks that need to be performed when booting into that runlevel. Under Red Hat, these files are typically symbolic links to shell scripts found in /etc/rc.d/init.d.
Let's put this all together with a simple example. Below are two sample lines from our inittab file:
id:3:initdefault: l3:3:wait:/etc/rc.d/rc 3
Here is a typical scenario of what happens under Red Hat. Once init is started, it reads /etc/inittab (see above). From the first line, we know that init is going to end up at a runlevel of 3 after the system boots. Once we reach that runlevel, the second line tells init to run the script /etc/rc.d/rc three and waits for it to terminate before proceeding.
The script rc in /etc/rc.d receives 3 as an argument. This 3 corresponds to a runlevel of 3. As a result, the rc script executes all the scripts in the /etc/rc.d/rc3.d directory. It first executes all the scripts that begin with the letter K (meaning “kill” the process or service) with an argument of “stop”. Next, it runs all the scripts that begin with the letter S with an argument of “start” to start the process or service. As one final note, the order of K and S script execution is based on sort order; the script named S90mysql would execute before the script named S95httpd.
It turns out the scripts in /etc/rc.d/rc3.d are actually symbolic links to scripts residing in /etc/rc.d/init.d. While the UNIX administrator can place scripts in rc3.d, the common practice under Red Hat is to first place all scripts in init.d, then create logical links to the rc*.d directories. It doesn't take long to figure out the creation and maintenance of these scripts and symbolic links could be quite the chore. That's precisely where chkconfig steps in! The Red Hat chkconfig utility is specifically designed to manage the symbolic links in /etc/rc.d/rc[0-6].d.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Profiles and RC Files
- Understanding Ceph and Its Place in the Market
- Astronomy for KDE
- Git 2.9 Released
- OpenSwitch Finds a New Home
- The Giant Zero, Part 0.x
- Maru OS Brings Debian to Your Phone
- SoftMaker FreeOffice
- What's Our Next Fight?
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide