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.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Web & UI Developer (JavaScript & j Query)
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Nice article, thanks for the
4 hours 14 min ago - I once had a better way I
10 hours 4 sec ago - Not only you I too assumed
10 hours 17 min ago - another very interesting
12 hours 10 min ago - Reply to comment | Linux Journal
14 hours 3 min ago - Reply to comment | Linux Journal
20 hours 57 min ago - Reply to comment | Linux Journal
21 hours 14 min ago - Favorite (and easily brute-forced) pw's
23 hours 5 min ago - Have you tried Boxen? It's a
1 day 4 hours ago - seo services in india
1 day 9 hours ago




Comments
Oracle shutdown not working
Hi,
thanks for this article.
One addition: Oracle doesn't shutdown automatically in RHEL5 if /var/lock/subsys/ isn't considered.
Please refer to .
Cheers,
Thomas
Oops... the most important
Oops... the most important information was truncated:
Refer to http://linux.derkeiler.com/Mailing-Lists/RedHat/2008-12/msg00037.html:
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:
start)
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
;;
stop)
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 thomas.gutzmann@gutzmann.com.
superb
Super Article....
Helped a lot Jimmy.
Cheers!!!
-Sandeep
Precise
Perfect writeup. Very useful
Thank you
Thank you! Oldie but goodie. Have been wanting to decipher this for years.
Thanks
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.
Thanks.
very interesting and useful
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
thanks
marco
excellent article
i just wanted to thank you for this great article !!
these line are magical:
#chkconfig: 2345 80 05
#description:
Managing Initscripts with Red Hat's chkconfig
This article was EXTREMELY useful! Thanks for writing it!
good job!!
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
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
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
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 sendmail.mc often has this in it:
define(`confDEF_USER_ID',``8:12'')
(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.
HTH,
--Charlie