Naturally, the typical /etc/inittab file has many more features than the three-line script shown above. Although bootwait and respawn are the most important actions, several other actions exist in order to deal with issues related to system management. I won't discuss them here.
Note that SysVinit can deal with ctrl-alt-del, whereas the versions of init shown earlier didn't catch the three-finger salute (i.e., the machine would reboot if you pressed the key sequence). Those interested in how this is done can check sys_reboot in /usr/src/linux/kernel/sys.c. (If you look in the code, you'll note the use of a magic number 672274793: can you imagine why Linus chose this number? I think I know the answer, but you'll enjoy discovering it yourself.)
Let's look at how a fairly complete /etc/inittab can take care of everything required to handle the needs of a system's lifetime, including different runlevels. Although the magic of the game is always on display in /etc/inittab, several different approaches to system configuration can be taken, the simplest being the three-line inittab shown above. In my opinion, two approaches are worth discussing in some detail; I'll call them “the Slackware way” and “the Debian way” from two renowned Linux distributions that chose to follow them.
Although it has been quite some time since I last installed Slackware, the documentation included in SysVinit-2.74 tells me that it still works the same. It has fewer features but is much faster than the Debian way. My personal 486 box runs a Slackware-like /etc/inittab just for the speed benefit.
The core of an /etc/inittab as used by a Slackware system is shown in Listing 3. Note that the runlevels 0, 1 and 6 have a predefined meaning. This is hardwired into the init command, or better, into the shutdown command part of the same package. Whenever you want to halt or reboot the system, init is told to switch to runlevel 0 or 6, thus executing /etc/rc.d/rc.0 or /etc/rc.d/rc.6.
This works flawlessly because whenever init switches to a different runlevel, it stops respawning any task not defined for the new runlevel; actually, it kills the running copy of the task. In this case, the active task is /sbin/agetty.
Configuring this setup is fairly simple, as the roles of the different files are clear:
/etc/rc.d/rc.S is run at system boot, independently of the runlevel. Add to this file anything you want to execute right at the start.
/etc/rc.d/rc.M is run after rc.S is over, only when the system is going to runlevels 2 through 5. If you boot at runlevel 1 (single user), this script is not executed. Add to this file anything you run only in multiuser mode.
/etc/rc.d/rc.K deals with killing processes when going from multi-user to single-user mode. If you add anything to rc.M, you'll probably want to stop it from rc.K.
/etc/rc.d/rc.0 and /etc/rc.d/rc.6 shut down and reboot the computer, respectively.
/etc/rc.d/rc.4 is executed only when runlevel 4 is entered. This file runs the “xdm” process, to allow graphic login. Note that no getty is run on /dev/tty1 when in runlevel 4 (this can be changed if you wish).
This kind of setup is easy to understand, and you can differentiate between runlevels 2, 3 and 5 by adding proper wait (execute once while waiting for termination) and respawn (execute forever) entries.
By the way, if you haven't guessed what “rc” means, it is the short form of “run command”. I had been editing my .cshrc and .twmrc files for years before being told what this arcane “rc” suffix meant—some things in the UNIX world are handed down only by oral tradition. I feel I'm now saving someone from years of being in the dark—and I hope I won't be punished for defining it in writing.
Although simple, the Slackware way to set up /etc/inittab doesn't scale well when adding new software packages to the system.
Let's imagine, for example, that someone distributes an ssh package as a Slackware add-on (not unlikely, as ssh can't be distributed on official disks due to the illogical U.S. rules about cryptography). The program sshd is a stand-alone server that must be invoked at system boot; this means the package should patch /etc/rc.d/rc.M or one of the scripts it invokes to add ssh support. This is clearly a problem in a world where packages are typically archives of files. In addition, you can't assume that rc.local is always unchanged from the stock distribution, so even a post-install script that patches the file will fail miserably when run in the typical user-configured computer.
You should also consider that adding a new server program is only part of the job; the server must also be stopped in rc.K, rc.0 and rc.6. Things are now getting quite tricky.
The solution to this problem is both clean and elaborate. The idea is that each package which includes a server must provide the system with a script to start and stop the service; each runlevel will then start or stop the services associated with that runlevel. Associating a service and a runlevel can be as easy as creating files in a runlevel-specific directory. This setup is common to Debian and Red Hat, and possibly other distributions that I have never run.
The core of the /etc/inittab used by Debian 1.3 is shown in Listing 4. The Red Hat setup features exactly the same structure for system initialization, but uses different path names; you'll be able to map one structure to the other. Let's list the roles of the different files:
/etc/init.d/boot is the exact counterpart of rc.S. It typically checks local file systems and mounts them, but the real thing has many more features.
/sbin/sulogin allows root to log in to a single-user workstation. Shown in Listing 4 only because single-user mode is so important for system maintenance.
/etc/init.d/rc is a script that runs any start/stop script belonging to the runlevel being entered.
The last item, the rc program, is the main character of this environment: its task consists in scanning the directory /etc/rc$runlevel.d and invoking any script located in that directory. A stripped-down version of rc would look like this:
#!/bin/sh level=$1 cd /etc/rc.d/rc$level.d for i in K*; do ./$i stop done for i in S*; do ./$i start doneWhat does this mean? It means that /etc/rc2.d (for example) includes files called K* and S*; the former identifies services that must be killed (or stopped), and the latter identifies services that must be started.
Okay, but I didn't explain where the K* and S* files come from. Each software package that must run for a particular runlevel adds itself to all the /etc/rc?.d directories, as either a start entry or a kill entry. To avoid code duplication, the package installs a script in /etc/init.d and several symbolic links from the various /etc/rc?.d directories.
To show a real-life example, lets's see what is included in two rc directories of Debian:
rc1.d: K11croni K20sendmail K12kerneld K25netstd_nfs K15netstd_init K30netstd_misc K18netbase K89atd K20gpm K90sysklogd K20lpd S20single K20ppp rc2.d: S10sysklogd S20sendmail S12kerneld S25netstd_nfs S15netstd_init S30netstd_misc S18netbase S89atd S20gpm S89cron S20lpd S99rmnologin S20ppp
The contents of these two directories show how entering runlevel 1 (single-user) kills all the services and starts a “single” script, and entering runlevel 2 (the default level) starts all the services. The number that appears near the K or the S is used to order the birth or death of the various services, as the shell expands wild cards appearing in /etc/init.d/rc in alphanumeric order. Invoking an ls -l command confirms that all of these files are symbolic links, such as the following:
rc2.d/S10sysklogd -> ../init.d/sysklogd rc1.d/K90sysklogd -> ../init.d/sysklogdTo summarize, adding a new software package in this environment means adding a file in /etc/init.d and the proper symbolic link from each of the /etc/rc?.d directories. To make different runlevels behave differently (2, 3, 4 and 5 are configured in the same way by default), just remove or add symbolic links in the proper /etc/rc?.d directories.
If this seems too difficult and discouraging, all is not lost. If you use Red Hat (or Slackware), you can think of /etc/rc.d/rc.local like it was autoexec.bat—if you are old enough to remember the pre-Linux age. If you run Debian, you could create /etc/rc2.d/S95local and use it as your own rc.local; note, however, that Debian is very clean about system setup, and I would rather not suggest such heresy. Powerful and trivial seldom match—you have been warned.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
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