This competency is so rudimentary and narrow in scope that it seems almost out of place on the domains and competencies chart when compared with others such as installing and configuring an Apache web server, but it’s certainly fundamental to system administration. As interpreted by the other major LFCE guide on the Internet (at TecMint), one need only understand basic use of the chkconfig command to satisfy the competency.
I’m going to expand on that scope, however. If that’s truly all that is demanded by the LFCE, then it’s not very rigorous in this area. Comprehension of the upstart init daemon is fundamental to administration of a CentOS 6 system, and its thorough understanding leads to much more confident and robust administrative capabilities.
Upstart’s Historical Context
While systemd is implemented in CentOS 7 and will likely be the wave of the Linux future, upstart is still relevant to a modern Linux professional who wants to understand the development choices and concerns facing init daemon developers. Upstart was designed to replace the old System V init daemon, and a nice concise explanation of its place in history can be found at almighty Wikipedia. Many debates have raged over the superiority or inferiority of systemd, and while most are just angry yelling masquerading as technical discussion, some are extremely interesting (see Russ Alberry’s technical analysis of systemd and upstart, for example).
Upstart: A Very Brief High-Level Administrative Overview
As written in the upstart guide linked below, “In essence, Upstart is an event engine: it creates events, handles the consequences of those events being emitted and starts and stops processes as required.”
In general, the upstart daemon starts itself and then the jobs described in /etc/init/*, one of which (/etc/init/rc.conf) executes the /etc/rc.d/rc script, passing it the current runlevel as its only argument. The /etc/rc.d/rc script then executes the scripts which live in /etc/init.d/ in the order of priority described by the symbolic links in /etc/rc.d/rc[runlevel].d. The /etc/rc.d/rc[runlevel].d directories are simply repositories of symbolic links which refer to scripts centrally located in /etc/init.d/. The purpose of these symbolic links is to allow for the ordering of script execution by altering the prefix of the symbolic link’s name in each rc directory which represents each runlevel. In fact, all chkconfig does is refer to and manage these symbolic links, adding, removing, and altering them based on user input. If chkconfig were to suddenly become unavailable, a well-read system administrator could survive without it.
Upstart monitors and maintains jobs during operation. For example, upstart will respawn processes if they die inappropriately and the developer has indicated in the appropriate /etc/init/*.conf (or *.override) file that the respawn option is desired. On your CentOS 6 box, you’ll find that there actually aren’t very many jobs (only 14 with a vanilla installation). The majority of your CentOS services, so to speak, are managed through rc scripts, which upstart manages by kicking off the job described by /etc/init/rc.conf whenever the runlevel event is emitted. The standard “service” command used to retrieve status information for jobs simply refers to the affiliated /etc/init.d/ script and executes the status function defined in that script.
Very practically, understanding the upstart init daemon will help you to avoid common pitfalls, such as attempting to manually kill processes to end service jobs only to watch them be respawned by upstart. You’ll know how to deliver environment variables to services and what files to edit when services misbehave. You’ll know how to deeply interrogate a system in response to service startup failures at boot, and all of this will be indispensable to you in practice.
- Upstart Intro, Cookbook, and Best Practices – great historical context and design rationale information along with the most thorough overview on the Internet. If you fully understand this document, you are in a very good place. At least read chapters 3 through 5 and 8, and scan chapters 6, 7, and 10. I recommend going through it alongside an operational VM so that you can investigate the features as you read about them. Take note that CentOS 6 uses upstart version 0.6.5.
- Manual pages
- initctl(8) – Usage of the start, stop, and other control commands for the init daemon
- chkconfig(8) – Usage of the chkconfig command to configure automatic daemon startup
- service(8) – Usage of the service command to query, start, and stop upstart services
- Red Hat Documentation
- RHEL 6 Deployment Guide Chapter 10.2.3 – Using the chkconfig Utility
- The Linux Bible, 8th Edition – Chapter 15
- initctl (start, stop)
- Configuring services to start automatically per runlevel
- Configuring services to start automatically per condition
- Executing non-service operations at startup
Honestly, you are probably going to be expected merely to be able to use chkconfig, but you never know. You may be asked to figure out why a service won’t start, or you might need to pass certain environment variables to the daemon when it does start.
- Ensure that a service starts up on runlevel 3 but not any other runlevel. Try changing runlevels and observing the behavior of the service.
- Produce a list of all services managed by chkconfig which do not start on the current runlevel.
- Create a simple script (Hello world, perhaps?) and ensure that it is executed once every time the system starts up.
- Create a task job which starts on the runlevel event and simply adds a timestamp to a file on your system. Change runlevels and ensure your job executes appropriately.
I’ll try to come up with some more witty tactical exercises, but this is a pretty narrow competency if I don’t just throw in more exercises regarding the upstart init daemon in general. The exercises here are already probably out of the scope of the exam.