Initialization Files and Boot Scripts

This section discusses the Unix initialization files: command scripts that perform nearly of the work associated with taking the system to multiuser manner. Although similar activities take place nether System V and BSD, the mechanisms past which they are initiated are quite different. Of the systems nosotros are considering, FreeBSD follows the traditional BSD style, AIX is a hybrid of the two, and all the other versions use the System V scheme.

Understanding the initialization scripts on your arrangement is a vital part of system assistants. You should have a pretty good sense of where they are located and what they do. That style, you'll be able to recognize whatsoever problems at boot time right abroad, and you'll know what cosmetic activity to take. Also, from time to time, you'll probably need to modify them to add new services (or to disable ones you've decided y'all don't need). We'll talk over customizing initialization scripts after in this chapter.

Although the names, directory locations, and bodily beat program code for arrangement initialization scripts varies widely between BSD-based versions of Unix and those derived from Organization Five, the activities accomplished past each fix of scripts every bit a whole differs in only minor ways. In loftier-level terms, the BSD kicking process is controlled by a relatively pocket-size number of scripts in the /etc directory, with names beginning with rc, which are executed sequentially. In dissimilarity, System V executes a large number of scripts (as high as 50 or more), organized in a 3-tiered hierarchy.

Tip

Unix initialization scripts are written using the Bourne beat out (/bin/sh). As a convenience, Bourne beat programming features are summarized in Appendix A.

Aspects of the kicking process are besides controlled past configuration files that change the operations of the kick scripts. Such files consist of a series of variable definitions that are read in at the beginning of a kick script and whose values determine which commands in the script are executed. These variables tin can specify things like whether a subsystem is started at all, the command-line options to employ when starting a daemon, and the similar. Generally, these files are edited manually, just some systems provide graphical tools for this purpose. The dialog on the left in Effigy iv-i shows the utility provided by SuSE Linux seven as function of its YaST2 administration tool.

Editing the boot script configuration file on a SuSE Linux system

Figure iv-one. Editing the boot script configuration file on a SuSE Linux organization

The dialog on the correct shows the new run-level editor provided by YaST2 on SuSE 8 systems. In this example, nosotros are enabling inetd in run levels 2, 3, and 5.

Initialization Files Under FreeBSD

The organization of arrangement initialization scripts on traditionalBSD systems such as FreeBSD is the essence of simplicity. In the by, boot-fourth dimension activities occurred via a series of only iii or four shell scripts, usually residing in /etc, with names beginning with rc. Under FreeBSD, this number has risen to about 20 (although not all of them apply to every system).

Multiuser-mode system initialization under BSD-based operating systems is controlled by the file /etc/rc. During a boot to multiuser way, init executes the rc script, which in turn calls other rc.* scripts. If the organization is booted to unmarried-user mode, rc begins executing when the single-user beat out is exited.

The kicking script configuration files /etc/default/rc.conf, /etc/rc.conf, and /etc/rc.conf.local control the functioning of the rc script. The first of these files is installed past the operating system and should non be modified. The other two files comprise overrides to settings in the first file (although the latter is seldom used).

Here are some case entries from /etc/rc.conf:

accounting_enable="YES" check_quotas="YES" defaultrouter="192.168.29.204" hostname="ada.ahania.com" ifconfig_xl0="inet 192.168.29.216 netmask 255.255.255.0" inetd_enable="Yes" nfs_client_enable="Aye" nfs_server_enable="Yeah" portmap_enable="YES" sendmail_enable="NO" sshd_enable="YES"

This file enables the bookkeeping, inetd, NFS, portmapper, and ssh subsystems and disables sendmail. It causes disk quotas to exist checked at boot time, and specifies various network settings, including the Ethernet interface.

Initialization Files on System V Systems

The system initialization scripts on a System V-way system are much more than numerous and complexly interrelated than those under BSD. They all revolve around the notion of the electric current system run level, a concept to which we now turn.

System V run levels

At any given time, a computer system tin be in i of 3 conditions: off (not running, whether or not it has power), single-user mode, or multiuser fashion (normal operating conditions). These three weather condition may be thought of equally iii implicitly defined system states.

System V-based systems take this idea to its logical extreme and explicitly ascertain a series of organization states, called run levels, each of which is designated past a ane-character name that is usually a number. At whatever given time, the system is at one of these states, and it tin exist sent to another 1 using various administrative commands. The defined run levels are listed in Tabular array 4-2.

Table 4-ii. Arrangement 5-style run levels

Run Level

Proper noun and customary purpose

0

Halted state: weather under which information technology is safe to turn off the power.

1

System assistants/maintenance state.

Due south and s

Single-user way.

2

Multiuser manner: the normal operating state for isolated, non-networked systems or networked, not-server systems, depending on the version of Unix.

3

Remote file sharing country: the normal operating state for server systems on networks that share their local resources with other systems (irrespective of whether networking and resource sharing occurs via TCP/IP and NFS or some other protocol).

4, 7, 8, 9

Administrator-definable system states: a mostly unused run level, which tin be set and defined locally.

5

Same as run level iii only running a graphical login program on the system console (eastward.g., xdm).

six

Shutdown and reboot state: used to reboot the system from some running state (s, two, 3, or 4). Moving to this land causes the system to be taken down (to run level 0) and then immediately rebooted back to its normal operating state.

Q and q

A pseudo-land that tells init to reread its configuration file /etc/inittab.

a, b, c

Pseudo-run levels that can exist divers locally. When invoked, they cause init to run the commands in /etc/inittab corresponding to them without changing the current (numeric) run level.

In most implementations, states 1 and south/S are non distinguished in practice, and not all states are predefined by all implementations. State 3 is the defined normal operating fashion for networked systems. In practice, some systems collapse run levels 2 and 3, supporting all networking functions at run level two and ignoring run level iii, or making them identical so that two and 3 get alternate names for the aforementioned system state. We will utilise separate run levels 2 and 3 in our examples, making run level 3 the system default level.

Note that the pseudo-run levels (a, b, c, and q/Q) do not correspond singled-out system states, only rather function every bit ways of getting init to perform sure tasks on need.

Table 4-3 lists the run levels defined by the various operating systems we are considering. Notation that FreeBSD does non apply run levels.

Table 4-iii. Run levels defined past various operating systems

AIX

HP-UX

Linux

Tru64

Solaris

Default run level

ii

3

3 or five

three

3

Q

yes

aye

yeah

aye

aye

7, viii, 9

yeah

no

yes

yes

no

a, b, c

yep

yes

yes

no

yep

The command who -r may be used to display the current run level and the fourth dimension it was initiated:

$                                  who -r                                . run level 3  Mar 14 11:14  3  0  S                                  Previous run level was S.

The output indicates that this system was taken to run level 3 from run level S on March 14. The 0 value between the 3 and the South indicates the number of times the organization had been at the electric current run level immediately prior to entering information technology this time. If the value is nonzero, information technology oft indicates previous unsuccessful boots.

On Linux systems, the runlevel command lists the previous and electric current run levels.

Now for some concrete examples. Let's assume a system whose normal, everyday system land is state 3 (networked multiuser mode). When you kick this system later on the power has been off, it moves from state 0 to country 3. If you lot shut the arrangement down to single-user mode, it moves from land 3 through state 0 to state s. When you reboot the system, it moves from state 3 through land 6 and state 0, and so back to state 3.[12]

Using the telinit command to change run levels

The telinit utility may be used to change the current systemrun level. Its name comes from the fact that it tells the init procedure what to exercise adjacent. It takes the new run level as its argument. The following command tells the system to reboot:

#                                  telinit 6

Tru64 does not include the telinit command. However, because telinit is just a link to init that has been given a dissimilar name to highlight what it does, you can easily create information technology if desired:

#                                  cd /sbin                                #                                  ln init telinit

You can besides just employ init itself: init 6.

AIX also omits the telinit command, since information technology does not implement run levels in the usual manner.

Initialization files overview

Organization V-style systems organize the initialization proc ess in a much more complex way, using iii levels of initialization files:

  • /etc/inittab, which is init'due south configuration file.

  • A serial of chief scripts named rc n (where n is the run level), typically stored in /etc or /sbin.

  • A collection of auxiliary, subsystem-specific scripts for each run level, typically located in subdirectories named rcn.d nether /etc or /sbin.

  • In add-on, some systems also provide configuration files that define variables specifying or modifying the functioning of some of these scripts.

On a boot, when init takes control from the kernel, it scans its configuration file, /etc/inittab, to determine what to do next. This file defines init'south deportment whenever the system enters a new run level; it contains instructions to behave out when the organisation goes down (run level 0), when it boots to single-user fashion (run level S), when booting to multiuser mode (run level two or three), when rebooting (run level 6), and so on.

Each entry in the inittab configuration file implicitly defines a process to be run at one or more run levels. Sometimes, this process is an bodily daemon that continues executing as long as the arrangement remains in a given run level. More than oft, the process is a shell script that is executed when the arrangement enters one of the run levels specified in its inittab entry.

When the system changes run levels, init consults the inittab file to determine the processes that should be running at the new run level. It then kills all currently running processes that should not exist running at the new level and starts all processes specified for the new run level that are not already running.

Typically, the commands to execute at the start of each run level are independent in a script named rc n, where n is the run level number (these scripts are usually stored in the /etc directory). For example, when the system moves to run level ii, init reads the /etc/inittab file, which tells it to execute rc2. rc2 so executes the scripts stored in the directory /etc/rc2.d. Similarly, when a running system is rebooted, it moves offset from run level 2 to run level six, a special run level that tells the organization to close down and immediately reboot, where it usually executes rc0 and the scripts in /etc/rc0.d, and then changes to run level 2, again executing rc2 and the files in /etc/rc2.d. A few systems use a unmarried rc script and laissez passer the run level as its argument: rc ii.

A simple version of the Arrangement V rebooting process is illustrated in Figure 4-two (assuming run level two as the normal operating land). Nosotros volition explain all of the complexities and eccentricities in it as this section progresses.

Executing System V-style boot scripts

Figure 4-2. Executing System 5-style boot scripts

The init configuration file

Equally we've seen, pinnacle-level control of changing arrangement states is handled past the file /etc/inittab, read by init. This file contains entries that tell the system what to exercise when it enters the various divers system states.

Entries in the inittab have the following course:

                                  cc                :                  levels                :                  activeness                :                  procedure

where cc is a unique, example-sensitive label identifying each entry (subsequent entries with duplicate labels are ignored).[13] levels is a list of run levels to which the entry applies; if it is blank, the entry applies to all of them. When the system enters a new state, init processes all entries specified for that run level in the inittab file, in the lodge they are listed in the file.

procedure is the control to execute, and action indicates how init is to care for the process started past the entry. The most of import action keywords are the following:

wait

Start the process and wait for it to finish before going on to the side by side entry for this run state.

respawn

Kickoff the process and automatically restart it when it dies (normally used for getty last line server processes).

once

Start the process if it's not already running. Don't await for it.

boot

Execute entry only at boot time; start the process but don't wait for it.

bootwait

Execute entry but at kick fourth dimension and wait for information technology to finish.

initdefault

Specify the default run level (the one to reboot to).

sysinit

Used for activities that need to be performed before init tries to access the system console (for example, initializing the appropriate device).

off

If the process associated with this entry is running, kill it. Also used to comment out unused concluding lines.

Comments may be included on separate lines or at the cease of any entry by preceding the annotate with a number sign (#).

Here is a sample inittab file:

# ready default init level -- multiuser way with networking  is:3:initdefault:  # initial boot scripts  fs::bootwait:/etc/bcheckrc </dev/panel >/dev/console 2>&one  br::bootwait:/etc/brc </dev/console >/dev/console two>&1  # shutdown script  r0:06:wait:/etc/rc0  >/dev/console 2>&i </dev/console  # run level changes  r1:1:expect:/sbin/shutdown -y -iS -g0 >/dev/console 2>&1  r2:23:wait:/etc/rc2 >/dev/console 2>&ane </dev/console  r3:3:wait:/etc/rc3  >/dev/console 2>&1 </dev/console  pkg:23:once:/usr/sfpkg/sfpkgd    # starting time daemon directly  # off and reboot states  off:0:wait:/sbin/uadmin ii 0 >/dev/console 2>&1 </dev/panel  rb:6:await:/sbin/uadmin two 1 >/dev/console ii>&i </dev/console  # terminal initiation  co:12345:respawn:/sbin/getty console console  t0:234:respawn:/sbin/getty tty0 9600  t1:234:respawn:/sbin/getty tty1 9600  t2:234:off:/sbin/getty tty2 9600  # special run level  acct:a:once:/etc/start_acct      # first bookkeeping

This file logically consists of seven major sections, which we've separated with blank lines. The first department, consisting of a single entry, sets the default run level, which in this example is networked multiuser style (level iii).

The second department contains processes started when the system is booted. In the sample file, this consists of running the /etc/bcheckrc and /etc/brc preliminary kick scripts commonly used on System V systems in addition to the rcn structure. The bcheckrc script's master function is to prepare the root filesystem and other critical filesystems like /usr and /var. Both scripts are allowed to complete before init goes on to the side by side inittab entry.

The third section of the sample inittab file specifies the commands to execute whenever the system is brought downwards, either during a system shutdown and halt (to run level 0) or during a reboot (run level 6). In both cases, the script /etc/rc0 is executed, and init waits for it to finish before proceeding.

The 4th section, headed "run level changes," specifies the commands to run when system states i, 2, and three brainstorm. For land 1, the shutdown command listed in the sample file takes the arrangement to unmarried-user mode. Some systems execute the rc1 initialization file when the system enters state 1 instead of a shutdown control like the one above.

For state two, init executes the rc2 initialization script; for state iii, init executes rc2 followed past rc3. In all iii states, each process is allowed to finish before init goes on to the side by side entry. The last entry in this section starts a procedure directly instead of calling a script. The sfpkgd daemon is started only in one case per run level, when the system first enters run level 2 or 3. Of form, if the daemon is already running, it will not exist restarted.

The fifth section specifies commands to run (after rc0) when the system enters run levels 0 and six. In both cases, init runs the uadmin command, which initiates arrangement shutdown. The arguments to uadmin specify how the shutdown is to exist handled. Many mod systems accept replaced this legacy control, folding its functionality into the shutdown command (equally nosotros'll see shortly). Of the System V systems nosotros are considering, just Solaris still uses uadmin.

The sixth section initializes the organisation's last lines via getty processes (which are discussed in Chapter 12).

The final section of the inittab file illustrates the use of special run level a. This entry is used only when a telinit a command is executed by the system ambassador, at which point the start_acct script is run. The run levels a, b, and c are available to be defined as needed.

The rcn initialization scripts

As we've seen, init typically executes a script named rc north when entering run level n (rc2 for land ii, for example). Although the boot (or shutdown) process to each system state is controlled past the associated rc n script, the bodily commands to exist executed are stored in a series of files in the subdirectory rcn.d. Thus, when the organization enters state 0, init runs rc0 (as directed in the inittab file), which in turn runs the scripts in rc0.d.

The contents of an atypically small-scale rc2.d directory (on a system that doesn't utilize a divide run level 3) are listed below:

$                                  ls -C /etc/rc2.d                                K30tcp           S15preserve    S30tcp     S50RMTMPFILES   K40nfs           S20sysetup     S35bsd     S75cron  S01MOUNTFSYS     S21perf        S40nfs     S85lp

All filenames begin with one of ii initial filename characters (Due south and Chiliad), followed by a 2-digit number, and they all end with a descriptive name. The rcn scripts execute the K-files (as I'll call them) in their associated directory in alphabetical club, followed by the Due south-files, likewise in alphabetical club (this scheme is easiest to empathise if all numbers are the same length; hence the leading zeros on numbers under 10). Numbers exercise not demand to be unique.

In this directory, files would be executed in the order K30tcp, K40nfs, S01MOUNTFSYS, S15preserve, then on, ending with S75cron and S85lp. K-files are more often than not used to kill processes (and perform related functions) when transitioning to a different land; S-files are used to start processes and perform other initialization functions.

The files in the rc*.d subdirectories are usually links to those files in the subdirectory init.d, where the real files alive. For example, the file rc2.d/S30tcp is really a link to init.d/tcp. You meet how the naming conventions work: the final portion of the name in the rcn.d directory is the same every bit the filename in the init.d directory.

The file K30tcp is also a link to init.d/tcp. The same file in init.d is used for both the impale and kickoff scripts for each subsystem. The M and S links tin can be in the same rcn.d subdirectory, as is the case for the TCP/IP initialization file, or in different subdirectories. For example, in the case of the print spooling subsystem, the S-file might exist in rc2.d while the K-file is in rc0.d.

The same file in init.d can exist put to both uses considering it is passed a parameter indicating whether information technology was run every bit a Chiliad-file or an S-file. Here is an example invocation, from an rc2 script:

# If the directory /etc/rc2.d exists,  # run the Chiliad-files in information technology ...  if [ -d /etc/rc2.d ]; and then     for f in /etc/rc2.d/K*     {        if [ -s ${f} ]; then  #        pass the parameter "end" to the file          /bin/sh ${f} stop        fi     } # and and so the S-files:     for f in /etc/rc2.d/S*     {        if [ -s ${f} ]; then  #        laissez passer the parameter "start" to the file          /bin/sh ${f} start        fi     }  fi

When a K-file is executed, it is passed the parameter stop; when an Due south-file is executed, it is passed start. The script file will use this parameter to figure out whether it is beingness run as a G-file or an S-file.

Here is a elementary example of the script file, init.d/cron, which controls the cron facility. Past examining information technology, y'all'll be able to meet the basic construction of a System V initialization file:

#!/bin/sh  case $1 in    # commands to execute if run equally "Snncron"     'starting time')       # remove lock file from previous cron        rm -f /usr/lib/cron/FIFO       # start cron if executable exists        if [ -x /sbin/cron ]; and then          /sbin/cron          repeat "starting cron."        fi     ;;     # commands to execute if run as "Knncron"     'stop')           pid=`/bin/ps -eastward | grep ' cron$' | \             sed -due east 's/^  *//' -eastward 'southward/ .*//'`          if [ "${pid}" != "" ]; then             kill ${pid}          fi      ;;     # handle other arguments     *)        repeat "Usage: /etc/init.d/cron {beginning|stop}"        exit 1     ;;  esac

The first section in the example statement is executed when the script is passed kickoff as its first statement (when it'south an South-file); the second section is used when information technology is passed finish, as a K-file. The commencement commands remove any old lock file and then start the cron daemon if its executable is present on the system. The end commands effigy out the procedure ID of the cron process and kill it if it'south running. Some scripts/operating systems define additional valid parameters, including restart (equivalent to finish then kickoff) and status.

The file /etc/init.d/cron might be linked to both /etc/rc2.d/S75cron and /etc/rc0.d/K75cron. The cron facility is then started by rc2 during multiuser boots and stopped past rc0 during system shutdowns and reboots.

Sometimes scripts are even more than general, explicitly testing for the atmospheric condition under which they were invoked:

set `who -r`                                  Decide previous run level.                                                  if [ $viii != "0" ]                                  The return code of the previous state change.                                                  and so     leave  fi  instance $arg1 in 'start')     if [ $9 = "South" ]                                  Bank check the previous run level.                                then        echo "Starting process accounting"        /usr/lib/acct/startup     fi     ;; ...

This file uses diverse parts of the output from who -r:

$                                  who -r                                .  run level 2   Mar 14 11:14   2    0    S

The set command assigns successive words in the output from the who command to the shell script arguments $1 through $9. The script uses them to test whether the current organisation state was entered without errors, exiting if it wasn't. It likewise checks whether the immediately previous land was unmarried-user mode, as would be the instance on this organisation on a boot or reboot. These tests ensure that accounting is started only during a successful boot and non when single-user way has been entered due to boot errors or when moving from 1 multiuser state to another.

Boot script configuration files

On many systems, the operation of the various boot scripts tin exist controlled and modified past settings in 1 or more related configuration files. These settings may enable or disable subsystems, specify command-line arguments for starting daemons, and the similar. Generally, such settings are stored in separate files named for the corresponding subsystem, but sometimes they are all stored in a single file (as on SuSE Linux systems, in /etc/rc.config).

Hither are two configuration files from a Solaris system; the commencement is /etc/default/sendmail:

DAEMON=yes                                  Enable the daemon.                                QUEUE=1h                                  Set the poll interval to i hour.

The next file is /etc/default/samba:

# Options to smbd SMBDOPTIONS="-D" # Options to nmbd NMBDOPTIONS="-D"

The first example specifies whether the associated daemon should be started, as well as 1 of its arguments, and the 2d file specifies the arguments to be used when starting the ii Samba daemons.

File location summary

Tabular array 4-4 summarizes the boot scripts and configuration files used by the various Arrangement V-style operating systems we are considering. A few notes about some of them volition follow.

Table four-4. Kicking scripts for System V-style operating systems

Component

Location

inittab file

Usual : /etc

rc* files

Usual : /sbin/rcn

AIX : /etc/rc.*

HP-UX : /sbin/rc due north [fourteen]

Linux : /etc/rc.d/rc n a

rcn.d and init.d subdirectories

Usual : /sbin/rc north .d and /sbin/init.d

AIX : /etc/rc.d/rc n .d (but they are empty)

Linux : /etc/rc.d/rc n .d and /etc/rc.d/init.d (Ruby Hat); /etc/init.d/rc due north .d and /etc/init.d (SuSE)

Solaris : /etc/rc n .d and /etc/init.d

Kick script configuration files

AIX : none used

FreeBSD : /etc/rc.conf , and/or /etc/rc.conf.local

HP-UX : /etc/rc.config.d/*

Linux : /etc/sysconfig/* (Red Hat, SuSE eight); /etc/rc.config and /etc/rc.config.d/* (SuSE vii)

Solaris : /etc/default/*

Tru64 : /etc/rc.config

[fourteen] n is the parameter to rc.

Solaris initialization scripts

Solaris uses a standard Organisation Five boot script scheme. The script rcS (in /sbin) replaces bcheckrc, merely information technology performs the same functions. Solaris uses separate rcn scripts for each run level from 0 through 6 (excluding rc4, which a site must create on its own), simply the scripts for run levels 0, five, and vi are just links to a single script, chosen with different arguments for each run level. In that location are divide rcn.d directories for run levels 0 through 3 and S.

Unlike on some other systems, run level 5 is a "firmware" (maintenance) mode, defined as follows:

s5:5:expect:/sbin/rc5        >/dev/msglog 2>&1 </dev/panel of:five:expect:/sbin/uadmin two 6 >/dev/msglog 2>&i </dev/console

These entries illustrate the Solaris msglog device, which sends output to one or more than console devices via a single redirection operation.

Solaris inittab files also usually contain entries for the Service Access Facility daemons, such as the following:

sc:234:respawn:/usr/lib/saf/sac -t 300 ... co:234:respawn:/usr/lib/saf/ttymon ...

Run level 3 on Solaris systems is gear up every bit the remote file-sharing land. When TCP/IP is the networking protocol in employ, this means that general networking and NFS client activities—such as mounting remote disks—occur equally part of run level 2, merely NFS server activities do not occur until the organisation enters run level iii, when local filesystems become bachelor to other systems. The rc2 script, and thus the scripts in rc2.d, are executed for both run levels by an inittab entry similar this one:

s2:23:expect:/sbin/rc2 ...

Tru64 initialization scripts

Tru64 feels generally like a BSD-fashion operating arrangement. Its initialization scripts are 1 of the few places where its true, System 5-style origins are revealed. It uses bcheckrc to bank check (if necessary) and mountain the local filesystems.

Tru64 defines simply 4 run levels: 0, Due south, 2, and three. The latter two differ in that run level 3 is the normal, fully networked country and is usually init's default run level. Run level 2 is a nonnetworked state. Information technology is designed and then that it can be invoked easily from a arrangement at run level 3. The /sbin/rc2.d directory contains a multitude of K-files designed to terminate all of the diverse network servers and network-dependent subsystems. Most of the K-files operate past running the ps command, searching its output for the PID of a specific server process, so killing it if it is running. The bulk of the S-files in the subdirectory leave immediately if they are run at whatsoever time other than a boot from unmarried-user style. Taken together, the files in rc2.d ensure a functional but isolated system, whether run level 2 is reached every bit function of a boot or reboot, or via a transition from run level 3.

Linux initialization scripts

Most Linux systems use a vanilla, Arrangement V-style kick script hierarchy. The Linux init package supports the special action keyword ctrlaltdel that allows you lot to trap CTRL-ALT-DELETE sequences (the standard method of rebooting a PC), every bit in this example, which calls the shutdown command and reboots the organisation:

ca::ctrlaltdel:/sbin/shutdown -r at present

Linux distributions also provide custom initial boot scripts (run prior to rc). For example, Ruby-red Hat Linux uses /etc/rc.d/rc.sysinit for this purpose, and SuSE Linux systems apply /etc/init.d/boot. These scripts focus on the earliest kick tasks such as checking and mounting filesystems, setting the time zone, and initializing and activating swap infinite.

AIX: Making System V work similar BSD

It'due south possible to eliminate most of the layers of initialization scripts that are standard under Organisation 5. Consider this AIX inittab file:

init:2:initdefault:  brc::sysinit:/sbin/rc.boot 3 >/dev/console 2>&1 rc:ii:wait:/etc/rc ii>&1 | alog -tboot > /dev/panel srcmstr:2:respawn:/usr/sbin/srcmstr tcpip:two:wait:/etc/rc.tcpip > /dev/panel ii>&ane   nfs:2:await:/etc/rc.nfs > /dev/console 2>&ane   ihshttpd:two:look:/usr/HTTPServer/bin/httpd > /dev/console 2>&i  cron:ii:respawn:/usr/sbin/cron qdaemon:2:wait:/usr/bin/startsrc -sqdaemon cons::respawn:/etc/getty /dev/console  tty0:2:respawn:/etc/getty /dev/tty0

Other than starting a server process for the system console and executing the file /etc/bcheckrc at boot time, nothing is defined for any run level other than state 2 (multiuser mode).

This is the approach taken past AIX. When the system enters state 2, a series of initialization files are run in sequence: in this case, /etc/rc, /etc/rc.tcpip, and /etc/rc.nfs (with the System Resources Controller starting upwards in the midst of them). So several daemons are started via their own inittab entries. After the scripts consummate, getty processes are started. Since /etc/rcnorthward.d subdirectories are not used at all, this setup is a little dissimilar from that used on BSD systems.

More than recent AIX operating organisation revisions do include hooks for other run levels, modifying the preceding inittab entries in this way:

# Note that even run level 6 is included! tcpip:23456789:wait:/etc/rc.tcpip > /dev/panel 2>&1

The /etc/rc.d/rcn.d subdirectories are provided, but they are all empty.

Customizing the Boot Process

Sooner or afterward, yous will want to make additions or modifications to the standard boot process. Making additions is less risky than irresolute existing scripts. We'll consider the ii types of modifications separately.

Notation

Earlier adding to or modifying system kicking scripts, you should be very familiar with their contents and sympathise what every line within them does. Yous should also salvage a copy of the original script so yous tin can easily restore the previous version should problems occur.

Calculation to the boot scripts

When you want to add commands to the boot process, the starting time matter you need to determine is whether in that location is already support for what you want to do. See if in that location is an easy way to get what you lot want: changing a configuration file variable, for example, or adding a link to an existing file in init.d.

If the operating organization has made no provisions for the tasks yous desire to accomplish, you must next effigy out where in the process the new commands should be run. It is easiest to add items at the end of the standard boot procedure, but occasionally this is non possible.

Information technology is best to isolate your changes from the standard system initialization files as much as possible. Doing so makes them easier to test and debug and also makes them less vulnerable to being lost when the operating organization is upgraded and the previous boot scripts are replaced by new versions. Under the BSD scheme, the best way to reach this is to add a line to rc (or whatsoever other script that you demand to modify) that calls a split up script that you provide:

. /etc/rc.site_specific >/dev/panel 2>&1

Ideally, y'all would identify this at the end of rc, and the additional commands needed on that system would be placed into the new script. Notation that the script is sourced with the dot command and then that it inherits the current environment from the calling script. This does constrain information technology to being a Bourne beat script.

Tip

Some systems contain hooks for an rc.local script specifically designed for this purpose (stored in /etc like rc). FreeBSD does—it is called near the end of rc—simply you will have to create the file yourself.

On Organization 5 systems, there are more options. One arroyo is to add one or more additional entries to the inittab file (placing them as late in the file every bit possible):

site:23:await:/etc/rc.site_specific >/dev/panel 2>&1  h96:23:once:/usr/local/bin/h96d

The commencement entry runs the same shell script we added before, and the 2nd entry starts a daemon process. Starting a daemon straight from inittab (rather than from some other initialization file) is useful in 2 circumstances: when you desire the daemon started but at kicking time and when you want information technology to be restarted automatically if information technology terminates. Yous would use the inittab actions once and respawn, respectively, to produce these two ways of handling the inittab entry.

Alternatively, if your additions demand to take place at a very specific point in the kick process, you will need to add together a file to the appropriate rcn.d subdirectories. Post-obit the System V practice is all-time in this example: identify the new file in the init.d directory, giving information technology a descriptive proper name, and then create links to other directories as needed. Choose the filenames for the links carefully, so that your new files are executed at the proper point in the sequence. If yous are in uncertainty, executing the ls -ane command in the appropriate directory provides you with an unambiguous list of the current ordering of the scripts within it, and you lot will be able to decide what number to utilize for your new one.

Eliminating sure kicking-time activities

Disabling parts of the boot procedure is too relatively piece of cake. The method for doing and then depends on the initialization scripts used by your operating organisation. The diverse possibilities are (in decreasing order of preference):

  • Disable a subsystem past setting the corresponding control variable to no or 0 in one of the boot script configuration files. For example:

    sendmail_enable="no"

  • Remove the link in the rcn.d directory to the init.d directory in the instance of Organization Five-style kicking scripts. Alternatively, y'all can rename the link, for instance, by adding some other character to the beginning (I add together an underscore: _K20nfs). That way, information technology is easy to reinstate the file later.

  • In some cases, you lot will demand to comment out an entry in /etc/inittab (when a daemon that you don't desire is started directly).

  • Annotate out the relevant lines of initialization scripts that you don't want to use. This is the but choice under FreeBSD when no rc.conf parameter has been defined for a command or subsystem.

Linux systems often provide graphical utilities for adding and removing links to files in init.d. Figure iv-3 illustrates the ksysv utility running on a Red Hat Linux organisation.

Modifying boot script links

Figure 4-3. Modifying boot script links

The main window lists the scripts assigned as Southward-files (upper lists) and K-files for each run level. The Available Services list shows all of the files in init.d. You can add a script by dragging it from that list box to the advisable run level pane, and you lot tin remove one past dragging information technology to the trash can (we are in the procedure of deleting the abrasive Kudzu hardware detection utility in the example).

Clicking on whatsoever entry brings upward the smaller dialog at the bottom of the figure (both of whose panels are shown as separate windows). Yous can specify the location within the sequence of scripts using the Entry panel. The Service panel displays a brief description of the daemon's purpose and contains buttons with which you tin can start, cease, and restart information technology. If appropriate, you lot can utilize the Edit push button to view and potentially alter the startup script for this facility.

Modifying standard scripts

While it is ordinarily best to avert information technology, sometimes yous have no option merely to modify the commands in standard kicking scripts. For example, sure networking functions stopped working on several systems I accept intendance of immediately after an operating system upgrade. The reason was a bug in an initialization script, illustrated past the following:

# Check the mountain of /. If remote, skip balance of setup.  mount | grep ' / ' | grep ' nfs ' two>&1 > /dev/cypher  if [ "$?" -eq 0 ]  then      exit  fi

The second line of the script is trying to effigy out whether the root filesystem is local or remote—in other words, whether the system is a diskless workstation or not. It assumes that if it finds a root filesystem that is mounted via NFS, information technology must be a diskless organisation. All the same, on my systems, lots of root filesystems from other hosts are mounted via NFS, and this condition produced a false positive for this script, causing information technology to exit prematurely. The merely solution in a case like this is to fix the script so that your system works properly.

Whenever y'all modify a arrangement script, keep these recommendations in mind:

  • As a precaution, before modifying them in any style, copy the files you lot intend to alter, and write-protect the copies. Use the -p option of the cp control, if it is supported, to duplicate the modification times of the original files likewise equally their contents; this data tin be invaluable should you need to curl back to a previous, working configuration. For instance:

    #                                              cp -p /etc/rc /etc/rc.orig                                            #                                              cp -p /etc/rc.local /etc/rc.local.orig                                            #                                              chmod a-westward /etc/rc*.orig

    If your version of cp doesn't have a -p selection, employ a process like this one:

    #                                              cd /etc                                            #                                              mv rc rc.orig; cp rc.orig rc                                            #                                              mv rc.local rc.local.orig; cp rc.local.orig rc.local                                            #                                              chmod a-w rc.orig rc.local.orig

    Similarly, when you make further modifications to an already customized script, salvage a copy before doing so, giving information technology a dissimilar extension, such as .save. This makes the modification process reversible; in the worst case, when the organisation won't boot because of bugs in your new versions—and this happens to everyone—you can merely boot to single-user mode and copy the saved, working versions over the new ones.

  • Brand some provision for bankroll up modified scripts regularly and then that they can be restored easily in an emergency. This topic is discussed in particular in Chapter 11.

  • For security reasons, the organisation initialization scripts (including any quondam or saved copies of them) should be owned past root and not be writable by anyone but the possessor. In some contexts, protecting them against whatever not-root access is appropriate.

Guidelines for writing initialization scripts

Organisation boot scripts often provide both good and bad shell programming examples. If you write kick scripts or add commands to existing ones, keep these recommended programming practices in heed:

  • Use full pathnames for all commands (or use i of the other methods for ensuring that the proper control executable is run).

  • Explicitly test for the conditions under which the script is run if it is relying on the system beingness in some known country. Don't presume, for case, that there are no users on the organisation or that a daemon the script will exist starting isn't already running; have the script check to make sure. Initialization scripts often get run in other contexts and at times other than those for which their writers originally designed them.

  • Handle all cases that might ascend from any given action, not just the ones that you expect to result. This includes treatment invalid arguments to the script and providing a usage message.

  • Provide lots of informational and fault messages for the administrators who will see the results of the script.

  • Include enough of comments within the script itself.

Go Essential Arrangement Administration, 3rd Edition now with the O'Reilly learning platform.

O'Reilly members experience live online preparation, plus books, videos, and digital content from virtually 200 publishers.