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.
- Bruce Nikkel's Practical Forensic Imaging (No Starch Press)
- Transitioning to Python 3
- Progress on Privacy
- Stepping into Science
- Linux Journal December 2016
- Radio Free Linux
- CORSAIR's Carbide Air 740
- The Tiny Internet Project, Part II
- FutureVault Inc.'s FutureVault
- A Better Raspberry Pi Streaming Solution
Pick up any e-commerce web or mobile app today, and you’ll be holding a mashup of interconnected applications and services from a variety of different providers. For instance, when you connect to Amazon’s e-commerce app, cookies, tags and pixels that are monitored by solutions like Exact Target, BazaarVoice, Bing, Shopzilla, Liveramp and Google Tag Manager track every action you take. You’re presented with special offers and coupons based on your viewing and buying patterns. If you find something you want for your birthday, a third party manages your wish list, which you can share through multiple social- media outlets or email to a friend. When you select something to buy, you find yourself presented with similar items as kind suggestions. And when you finally check out, you’re offered the ability to pay with promo codes, gifts cards, PayPal or a variety of credit cards.Get the Guide