System Boot Process 13

Objectives
Upon completion of this module, you should be able to:

● Describe the four phases of the boot process

● Identify the directories that contain the kernel and its loadable
modules

● Modify the kernel’s configuration file

● Describe the eight Solaris Operating Environment run levels

● Define a system’s current run level using the who -r command

● Explain the purpose of the /etc/inittab file

● Describe the steps in the init process to bring a system to

multiuser mode

● List the directories that hold the run control scripts used to stop
and start system processes and services

● Describe the steps to add a new run control script

● Use the following commands to shut down the system: init,

shutdown, halt, poweroff, and reboot

13-1
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
Additional Resources
Additional resources – The following reference can provide additional
details on the topics discussed in this module:

● Solaris 8 System Administration Guide, Volume I, Sun Part Number

805-7228-10

13-2 Solaris 8™ Operating Environment System Administration I

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
The Solaris Operating Environment Run Levels

A run level is a digit or a letter representing a system state that defines

what services and resources are currently available to users. The
system is always running in one run level.

Run levels are sometimes referred to as init states because the init
process is used to transition between run levels. You can use the init
command to manually initiate run-level transitions.

The Solaris Operating Environment has eight run levels, which are
described in the following table.

Table 13-1 Solaris Run Levels

Run
Function
Level

0 Shuts down the Solaris Operating Environment and

displays the boot PROM ok prompt so it is safe to turn
off power to the system.
s or S Runs as single user with all file systems mounted and
accessible.
1 Indicates system is running in a single-user
administrative state with access to all available file
systems.
2 Indicates system is running in multi-user operations.
Multiple users can access the system. All system
daemons are running except for the NFS server
daemons.
3 Indicates sytem is running in multi-user operations
with NFS resource-sharing available. Specified as the
default run level in the /etc/inittab file.
4 This level is currently not implemented.
5 Shuts down the Solaris Operating Environment and
powers off the system.
6 Shuts down the system to run level 0, and then
reboots to multi-user operations, (or the level set in
the default in the /etc/inittab file).

System Boot Process 13-3

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
Determining a System’s Current Run Level
To determine the current run level of a system, use the following
command.
# who -r
. run level 3 Jun 9 08:30 3 0 S

Date and Time Current Previous

Current run level of last run level run level
run level
change
Number of times
at this run level
since last reboot

13-4 Solaris 8™ Operating Environment System Administration I

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
The Boot Process

In general, when a system is turned on, the PROM monitor runs a

quick self-test procedure that checks the hardware and memory on the
system. If no errors are found, the system begins the automatic boot
process.

The entire boot process is described by four distinct phases:

● Boot PROM phase

● Boot Programs phase

● Kernel Initialization phase

● init phase

System Boot Process 13-5

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13

PROM runs POST

boot locates boot-device

Boot PROM phase

boot reads bootblk

boot loads bootblk

bootblk loads secondary

boot program (ufsboot)

Boot Programs phase

ufsboot loads kernel
32-bit kernel
or
64-bit kernel

kernel initializes itself

and loads modules
Kernel Initialization phase
Reads configuration file
/etc/system

kernel starts
/etc/init
init phase

init starts rc scripts

Figure 13-1 Phases of the Boot Process

13-6 Solaris 8™ Operating Environment System Administration I

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
Boot PROM Phase
The following describes the Boot PROM phase:

● PROM runs POST

The boot PROM firmware runs the power on self test (POST) to
verify the system’s hardware and memory.

The PROM displays the system identification banner, (for

example, model type, amount of installed memory, PROM version
number, PROM serial number, Ethernet address, and host ID).

● boot determines the boot device.

● boot locates the bootblk on the boot device.

● boot loads the bootblk from its location on the boot device into
memory.

The primary boot program, bootblk, is located in a fixed location

on the boot device in sectors 1-15.

Its purpose is to load the secondary boot program located in the

ufs file system on the boot device.

Boot Programs Phase

The following describes the Boot Programs phase:

● bootblk loads the secondary boot program, ufsboot from the

boot device into memory.

The path to ufsboot is recorded in the bootblk, which is

installed by the Solaris utility installboot.

● ufsboot locates and loads the appropriate two-part kernel.

The kernel is comprised of a two-piece static core called genunix

and unix, where genunix is the platform-independent generic
kernel file and unix is the platform-specific kernel file.

When ufsboot loads these two files into memory, they are
combined to form the running kernel.

System Boot Process 13-7

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
On a 32-bit system, the two-part kernel is located in the directory
/platform/‘uname -m‘/kernel.

On a 64-bit system, the two-part kernel is located in the directory

/platform/‘uname -m‘/kernel/sparcv9.

Note – To determine the platform name (e.g. the system hardware

class), type the command uname -m. For example, by typing this
command on a Sun Ultra10 it would display: sun4u

The kernel Initialization Phase

The following describes the kernel Initialization phase:

● The kernel initializes itself and begins loading modules.

The kernel uses ufsboot to read the files. When it has loaded
enough modules to mount the root file system it unmaps the
ufsboot program and continues on.

● The kernel reads its configuration file called /etc/system.

● The kernel starts the /sbin/init process.

The SunOS kernel consists of a small, static core (genunix and unix)
and many dynamically loadable kernel modules.

Modules can consist of device drivers, file systems, streams, as well as

other types used for specific tasks within the system.

The modules which comprise the kernel typically reside in the

directories /kernel and /usr/kernel. Platform-dependent
modules reside in the /platform/‘uname -m‘/kernel and
/platform/‘uname -i‘/kernel directories.

Each subdirectory located under these directories is a collection of

similar-type modules.

13-8 Solaris 8™ Operating Environment System Administration I

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13

kernel

sys exec fs misc

sched strmod drv

genunix

Figure 13-2 Module Subdirectories in /kernel

The following describes the types of module subdirectories contained

in /kernel, /usr/kernel, /platform/‘uname -m‘/kernel, or
/platform/‘uname -i‘/kernel directories:

● sys – System calls (defined interfaces for applications to use)

● exec – Executable file formats

● fs – File system types, for example, ufs, nfs, and proc

● misc – Miscellaneous modules (virtual swap)

● sched – Scheduling classes (process execution scheduling)

● strmod – Streams modules (generalized connection between users

and device drivers)

● drv – Device drivers

The /kernel/drv directory contains all of the device drivers used for
system boot.

The directory /usr/kernel/drv is used for all other device drivers.

System Boot Process 13-9

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
Modules are loaded automatically as needed either at boot time or on
demand, if requested by an application. When a module is no longer
in use it is unloaded on the basis that the memory it uses up is needed
for another task.

The advantages of this dynamic kernel arrangement is the overall

size of the kernel is smaller making more efficient use of memory and
allowing for simpler modification and tuning.

32-bit Kernel MEMORY

/platform/‘uname -m‘/kernel/genunix
/platform/‘uname -m‘/kernel/unix
Static Core
64-bit Kernel genunix
/platform/‘uname -m‘/kernel/sparcv9/genunix
unix
/platform/‘uname -m‘/kernel/sparcv9/unix
Device Driver
Modules
Module directories Streams
Modules
/kernel
/usr/kernel
/platform/‘uname -m‘/kernel FS Modules
/platform/‘uname -i‘/kernel
Sched Modules

Figure 13-3 Kernel and Modules Loaded In Memory

Note – The sparcv9 is the type of CPU that supports 64-bit processing.

Configuring the kernel

The /etc/system file is the control file for specifying which modules
and parameters are to be loaded by the kernel at boot time. By default,
all lines in this file are commented out.

Modifying the kernel’s behavior (or configuration) requires editing the

/etc/system file. Altering this file allows the system administrator to
modify the kernel’s treatment of loadable modules, as well as kernel
parameters for some performance tuning.

13-10 Solaris 8™ Operating Environment System Administration I

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
The boot program contains a list of default loadable kernel modules
which are loaded at boot time. However, you can override this list by
modifying the /etc/system file to control which modules, as well as
parameters are loaded.

All changes to this file take effect after a reboot.

The /etc/system file explicitly controls:

● The search path for default modules to be loaded at boot time.

● The root type and device.

● The modules not to be loaded automatically at boot time.

● The modules to be forceable loaded automatically at boot time,

rather that at first access.

● The new values to override the default kernel parameter values.

Note – Command lines must be 80 characters or less in length and

comment lines must begin with an asterisk (*) and end with a newline
character.

System Boot Process 13-11

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
Sample /etc/system File

* ident "@(#)system 1.18 97/06/27 SMI" /* SVR4 1.5 */

* SYSTEM SPECIFICATION FILE
*
* moddir:
* Set the search path for modules. This has a format similar to the csh path
* variable. If the module isn’t found in the first directory it tries the second
* and so on. The default is /kernel /usr/kernel
* Example:
* moddir: /kernel /usr/kernel /other/modules
*
* root device and root filesystem configuration:
* The following may be used to override the defaults provided by the boot program:
* rootfs: Set the filesystem type of the root.
*
* rootdev: Set the root device. This should be a fully
* expanded physical pathname. The default is the
* physical pathname of the device where the boot
* program resides. The physical pathname is
* highly platform and configuration dependent.
* Example:
* rootfs:ufs
* rootdev:/sbus@1,f8000000/esp@0,800000/sd@3,0:a
* (Swap device configuration should be specified in /etc/vfstab.)
*
* exclude:
* Modules appearing in the moddir path which are NOT to be loaded, even if referenced.
* Note that ‘exclude’ accepts either a module name, or a filename which includes the
* directory.
* Examples:
* exclude: win
* exclude: sys/shmsys
*
* forceload:
* Cause these modules to be loaded at boot time, (just before mounting the root
* filesystem) rather than at first reference. Note that forceload expects a
* filename which includes the directory. Also note that loading a module does
* not necessarily imply that it will be installed.
* Example:
* forceload: drv/foo
*
* set:
* Set an integer variable in the kernel or a module to a new value.
* This facility should be used with caution. See system(4).
*
* Examples:
* To set variables in ’unix’:
* set nautopush=32
* set maxusers=40
* To set a variable named ’debug’ in the module named ’test_module’
* set test_module:debug = 0x13

13-12 Solaris 8™ Operating Environment System Administration I

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
The /etc/system file is divided into five distinct sections:

● moddir:

Sets the search path for default loadable kernel modules. You can
list together multiple directories to search, delimited either by
blank spaces or colons. If the module is not found in the first
directory, it tries the second directory, and so on.

● root device and root filesystem configuration:

Sets the root file system type to the listed value. The default is
rootfs:ufs

Sets the root device. The default is the physical pathname of the
device where the boot program resides. The physical pathname is
platform and configuration dependent. For example:
rootdev:/sbus@1,f8000000/esp@0,800000/sd@3,0:a

● exclude:

Does not allow the loadable kernel module(s) to be loaded

during kernel initialization. For example: exclude:
sys/shmsys

● forceload:

Forces the kernel module(s) to be loaded during kernel

initialization. For example: forceload: drv/vx

The default action is to automatically load a kernel module when

its services are first accessed during runtime, by a user or
application.

● set:

Changes kernel parameters to modify the operation of the system.

For example: set maxusers=40

Editing the /etc/system File

Before editing the /etc/system file, you should make a backup copy.
If you enter incorrect values in this file, the system might not be able to
boot.

System Boot Process 13-13

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
The following shows how to copy the original /etc/system file to a
backup file, and then edit the /etc/system file.
# cp /etc/system /etc/system.orig
# vi /etc/system

If a boot process fails because of an unusable /etc/system file, issue

the interactive boot command: boot -a. When requested to enter the
name of the system file, type in the name of your backup system file,
or alternatively enter: dev/null, for a null configuration file.

The init Phase

The final phase of the boot process is the /etc/init phase. During
this phase init start the run control scripts which starts other
processes.

The init process executes rc scripts which in turn execute a series of

other scripts

Once the init phase completes successfully, the system login prompt
is displayed.

13-14 Solaris 8™ Operating Environment System Administration I

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
The /etc/inittab File

When you boot a system, or changes run levels with the init or
shutdown command, the init daemon starts processes by reading
information from the /etc/inittab file.

The inittab file defines three important items for the init process:

● The system’s default run level.

● What processes to start, monitor, or restart if terminated.

● What actions to take when the system enters a new run level.

Each line entry in the /etc/inittab file has the following four
fields:

id:rstate:action:process

The fields in an inittab entry are described in the following table:

id A 1 to 4 character identifier for the entry.

rstate One or more run levels to which this entry applies.
action How the process (in the next field) is to be treated.
process The command or script to execute.

s3:3:wait:/sbin/rc3 > /dev/msglog 2<> /dev/msglog </dev/console

Figure 13-4 An /etc/inittab File Entry

Note – Message output from system startup (rc) scripts is directed to

/dev/msglog. Previously, all of these messages were written to
/dev/console. For more information refer to msglog(7D).

Some possible keywords used in the action field include:

initdefault Identifies the default run level. Read when init is

initially invoked. Used by init to determine which
run level to enter initially. The default is run level 3.

System Boot Process 13-15

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
Caution – If the rstate field is empty it is interpreted as 0123456
and init will enter run level 6, as the default. This will cause the
! system to reboot continuously.

sysinit Executes the process before init tries to access the

console (for example, the console login prompt). init
waits for its completion before it continues to read the
inittab file.

wait Starts the process and waits for it to complete before

moving to the next entry containing the same run
level.

respawn If the process dies, init will restart it. If the process
does not exist, init starts it and continues reading
the inittab file. If the process does exist, no action
required, and init continues reading the inittab
file.

powerfail Executes the process only if init receives a power

fail signal.

Note – Additional action keywords are available and defined in the

inittab man page.

13-16 Solaris 8™ Operating Environment System Administration I

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
Default /etc/inittab File
The following is an example of the default /etc/inittab file.
ap::sysinit:/sbin/autopush -f /etc/iu.ap
ap::sysinit:/sbin/soconfig -f /etc/sock2path
fs::sysinit:/sbin/rcS sysinit >/dev/msglog 2<>/dev/msglog </dev/console
is:3:initdefault:
p3:s1234:powerfail:/usr/sbin/shutdown -y -i5 -g0 >/dev/msglog
2<>/dev/msglog
sS:s:wait:/sbin/rcS >/dev/msglog 2<>/dev/msglog </dev/console
s0:0:wait:/sbin/rc0 >/dev/msglog 2<>/dev/msglog </dev/console
s1:1:respawn:/sbin/rc1 >/dev/msglog 2<>/dev/msglog </dev/console
s2:23:wait:/sbin/rc2 >/dev/msglog 2<>/dev/msglog </dev/console
s3:3:wait:/sbin/rc3 >/dev/msglog 2<>/dev/msglog </dev/console
s5:5:wait:/sbin/rc5 >/dev/msglog 2<>/dev/msglog </dev/console
s6:6:wait:/sbin/rc6 >/dev/msglog 2<>/dev/msglog </dev/console
fw:0:wait:/sbin/uadmin 2 0 >/dev/msglog 2<>/dev/msglog </dev/console
of:5:wait:/sbin/uadmin 2 6 >/dev/msglog 2<>/dev/msglog </dev/console
rb:6:wait:/sbin/uadmin 2 1 >/dev/msglog 2<>/dev/msglog </dev/console
sc:234:respawn:/usr/lib/saf/sac -t 300
co:234:respawn:/usr/lib/saf/ttymon -g -h -p "‘uname -n‘ console login: "
-T sun -d /dev/console -l console -m ldterm,ttcompat

The following describes each inittab line entry:

1. Initializes STREAMS modules

2. Configures socket transport providers

3. Initializes file systems

4. Defines default run level

5. Describes a power fail shutdown

6. Defines single-user mode

7. Defines run level 0

8. Defines run level 1

9. Defines run level 2

10. Defines run level 3

11. Defines run level 5

System Boot Process 13-17

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
12. Defines run level 6

13. Defines transition to firmware

14. Defines transition to power off

15. Defines transition to reboot

16. Initializes Service Access Controller

17. Initializes console

The init Process

The following illustrates the process of bringing a system to the
default run level 3.

/etc/inittab file /sbin/autopush

init process
Sets initdefault to run level 3 /sbin/soconfig

/sbin/rcS
Executes commands with a
sysinit entry in the action field
/sbin/rc2

Executes commands with a run

level 3 entry in the rstate field /sbin/rc3
fields
/usr/lib/saf/sac

/usr/lib/saf/ttymon

System Login

Figure 13-5 The init Process

13-18 Solaris 8™ Operating Environment System Administration I

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
The /etc/init process reads the /etc/inittab file to do the
following:

1. Identify the initdefault entry, which defines the default run

level 3.

2. Execute any process entries that have sysinit in the action field
so that any special initialization can take place before users login.

3. Execute any process entries that have 3 in the rstate field, which
matches the default run level, 3.

The commands executed at this run level include:

● /usr/sbin/shutdown – The init process runs the
shutdown command only if the system has received a
powerfail signal.
● /sbin/rcS – Mounts and checks / (root), /usr, /var,
and /var/adm file systems.
● /sbin/rc2 – Starts the system daemons, bringing the
system up into run level 2 (multi-user mode).
● /sbin/rc3 – Starts NFS resource sharing for run level 3.
● /usr/lib/saf/sac – Starts or restarts the port monitors
and network access for UUCP.
● /usr/lib/saf/ttymon – Starts or restarts the ttymon
process that monitors the console for login requests. The
terminal_type on a SPARC-based system is sun. The
terminal_type on an IA-based system is AT386.

System Boot Process 13-19

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
Run Control Scripts

The Solaris Operating Environment provides a series of run control

(rc) scripts to stop and start processes normally associated with run
levels.

The /sbin Directory

Each run level has an associated rc script located in the /sbin
directory.
/

sbin

rc0 rc1 rc2 rc3 rc5 rc6 rcS

Figure 13-6 The /sbin Directory

The rc scripts are executed by init to set up variables, test conditions,

and make calls to other scripts that start and stop processes for that
run level.

The rc scripts rc0, rc5 and rc6 files are hard linked. For example:
# cd /sbin
# ls -i rc*
47154 rc0 47156 rc2 47154 rc5 47158 rcS
47155 rc1 47157 rc3 47154 rc6

SunOS provides the same series of rc scripts in the /etc directory for
backward compatibility.

These scripts are symbolic link files to the rc scripts in the /sbin
directory.
# cd /etc
# ls -l rc?

13-20 Solaris 8™ Operating Environment System Administration I

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
lrwxrwxrwx 1 root root 11 Feb 22 14:19 rc0 -> ../sbin/rc0
lrwxrwxrwx 1 root root 11 Feb 22 14:19 rc1 -> ../sbin/rc1
lrwxrwxrwx 1 root root 11 Feb 22 14:19 rc2 -> ../sbin/rc2
lrwxrwxrwx 1 root root 11 Feb 22 14:19 rc3 -> ../sbin/rc3
lrwxrwxrwx 1 root root 11 Feb 22 14:19 rc5 -> ../sbin/rc5
lrwxrwxrwx 1 root root 11 Feb 22 14:19 rc6 -> ../sbin/rc6
lrwxrwxrwx 1 root root 11 Feb 22 14:19 rcS -> ../sbin/rcS
#

The /etc/rc#.d Directories

For each /sbin/rc script, there is a corresponding directory named
/etc/rc#.d.

The /etc/rc#.d directories contain additional scripts that start and

stop system processes for that run level.
/

/etc

rcS.d rc0.d rc1.d rc2.d rc3.d

K#script
S#script
S#script S#script
S#script
K#script K#script K#script

Figure 13-7 The /etc/rc#.d Directories

For example, /etc/rc2.d contains scripts used to start and stop

processes for run level 2.

# ls /etc/rc2.d

The /etc/rc#.d scripts are always run in the sort order shown by the
ls command. These files have names in the form of:

[KS][0-9][0-9]*

System Boot Process 13-21

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
Files beginning with K are run to terminate (kill) a system process.
Files beginning with S are run to start a system process.

Note – File names that begin with a lowercase k or s are ignored by

init and they are not executed. To disable a script, rename it with the
appropriate lowercase letter.

The /etc/init.d Directory

Run control scripts are located in the /etc/init.d directory. These
files are hard linked to corresponding run control scripts in the
/etc/rc#.d directories.

/etc

init.d

cron dtlogin lp nfs.server

Figure 13-8 The /etc/init.d Directory

The benefit of having individual scripts for each run level is that you
can run scripts in the /etc/init.d directory individually by root.
You can turn off a process or start a process without changing the
system’s run level.

For example, to stop and restart the lp print services, run the
following scripts with a stop or start command:
# /etc/init.d/lp stop

# /etc/init.d/lp start

13-22 Solaris 8™ Operating Environment System Administration I

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
Summary of Run Control Scripts and Functions

The following table summarizes the tasks that are performed by each
of the /sbin rc scripts.

Table 13-2 Run Control Scripts and Function

rc Script Function

/sbin/rc0 Runs the /etc/rc0.d/K* scripts to perform the following tasks

- Stops system services and daemons
- Terminates all running processes
- Unmounts all file systems
/sbin/rc1 Runs the /etc/rc1.d scripts to perform the following tasks:
- Stops system services and daemons
- Terminates all running processes
- Unmounts all file systems
/sbin/rc2 Runs the /etc/rc2.d scripts to perform the following tasks:
- Mounts all local file systems
- Removes any files in the /tmp directory
- Configures system accounting
- Configures default router
- Starts most of the system daemons
/sbin/rc3 Runs the /etc/rc3.d scripts to perform the following tasks:
- Cleans up /etc/dfs/sharetab file
- Starts nfsd and mountd
/sbin/rc5 Runs the /etc/rc0.d/K* scripts to perform the following tasks:
/sbin/rc6 - Kills all active processes and unmounts the file systems
/sbin/rcS Runs the /etc/rcS.d scripts to bring the system up to run level S.
- Establishes a minimal network
- Mounts /usr, if necessary
- Sets the system name
- Checks the / (root) and /usr file systems
- Mounts pseudo file systems (/proc and /dev/fd)
- Rebuilds the device entries for reconfiguration boots
- Mounts other file systems to be mounted in single-user mode

System Boot Process 13-23

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
Creating a New Run Control Script
You can create new scripts to start and stop additional processes or
services to customize a system.

For example, to eliminate the requirement for having to manually start

a database server, create a script to automatically start the database
server once the appropriate network services have started.

You could then create another script to terminate this service and shut
down the database server before the network services are stopped.

To add run control scripts to start and stop a service, create the script
in the /etc/init.d directory and create links in the appropriate
/etc/rc#.d directory for the run level the service is to be started and
stopped.

See the README file in each /etc/rc#.d directory for more information
on run control scripts.

The following procedure describes how to add a run control script:

1. Create the script in the /etc/init.d directory.

# vi /etc/init.d/filename
# chmod 0744 /etc/init.d/filename
# chown root:sys /etc/init.d/filename

2. Create links to the appropriate /etc/rc#.d directory.

# cd /etc/init.d
# ln filename /etc/rc#.d/S##filename
# ln filename /etc/rc#.d/K##filename

3. Use the ls command to verify that the script has links in the
appropriate directories.
# ls /etc/init.d /etc/rc#.d /etc/rc#.d

4. Test the filename by entering the following commands:

# /etc/init.d/filename start

13-24 Solaris 8™ Operating Environment System Administration I

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13

init 6 init 5
Multiuser mode
init 0
shutdown

exit

Single-User mode
halt
reboot

boot-s

boot
PROM Monitor (ok)
power off

power on

Power Off
power on

Figure 13-9 Run-Level Transitions

System Boot Process 13-25

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
System Shutdown Procedures

You can shut down the Solaris Operating Environment to perform

administration tasks or maintenance activities, in anticipation of a
power outage, or if you need to move the system to a new location.

The Solaris Operating Environment requires a clean and orderly

shutdown process, which stops processes, writes data in memory to
disk(s), and unmounts file systems.

Of course, the type of work you need to do determines how the

system is shut down and what command is used.

The following describes the different types of system shutdowns.

● Shut down the system to single-user mode

● Shut down the system to stop the Solaris Operating Environment

and display the ok prompt

● Shut down the system to turn off power

● Shut down the system automatically and reboot to multi-user

mode

The commands available to root for doing these types of system

shutdown procedures include:

● /sbin/init (using run levels S, 1, 0, 5 or 6)

● /usr/sbin/shutdown (using run levels S, 1, 0, 5 or 6)

● /usr/sbin/halt

● /usr/sbin/poweroff

● /usr/sbin/reboot

The /sbin/init Command

You can use the init command to shutdown, poweroff, or reboot
a system in a clean and orderly manner. It executes the rc0 kill scripts,
however, this command does not warn logged in users that the system
is being shutdown, and there is no delay.

13-26 Solaris 8™ Operating Environment System Administration I

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
To shut down the system to single-user mode, use either run level S or
1, for example:
# init S

To shut down the system to stop the Solaris Operating Environment

and display the ok prompt:
# init 0

To shut down the system and turn its power off:

# init 5

To shut down the system and then reboot to multi-user mode:

# init 6

The /usr/sbin/shutdown Command

The shutdown command is a script that invokes init to shutdown,
poweroff, or reboot the system. It does execute the rc0 kill scripts
to shutdown processes and applications gracefully. Unlike the init
command, the shutdown command does the following:

● Notifies all logged in users that the system is being shutdown

● Delays the shutdown for 60 seconds by default

● Gives you the capability to include an optional descriptive

message to inform your users

Command Format

shutdown [ -y ] [ -g grace-period ] [ -i init-state ] [ optional message ]

The -y option is used to pre-answer the final shutdown confirmation

question so the command runs without user intervention.

The -g grace-period allows root to change the number of seconds

from the 60-second default.

The -i init-state specifies the state init is to be in. By default,

system state S is used.

System Boot Process 13-27

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
To shut down the system to single-user mode, enter either run level S
or 1, for example:
# shutdown -iS

To shut down the system to stop the Solaris Operating Environment

and display the ok prompt:
# shutdown -i0

To shut down the system and turn off its power automatically:
# shutdown -i5

To shut down the system and then reboot to multi-user mode:

# shutdown -i6

The /usr/sbin/halt Command

The halt command performs an immediate shutdown. It does not
execute the rc0 kill scripts, it does not notify logged in users, and
there is no delay.

To shut down the system to stop the Solaris Operating Environment

and display the ok prompt:
# halt

The /usr/sbin/poweroff Command

The poweroff command performs an immediate shutdown. It does
not execute the rc0 kill scripts, no logged in users are notified, and
there is no delay.

To shut down the system and turn off its power:

# poweroff

13-28 Solaris 8™ Operating Environment System Administration I

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
The /usr/sbin/reboot Command
The reboot command performs an immediate shutdown and brings
the system to run level 3 by default. The reboot command differs
from the init 6 command because it does not execute the rc0 kill
scripts, and it does not notify logged in users.

To shutdown the system and then reboot to multi-user mode:

# reboot

System Boot Process 13-29

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
Exercise: The Boot Process

Exercise objective – In this exercise you create a new startup script,

make changes in /etc/system, and observe their effects.

Preparation
Refer to the lecture notes as necessary to perform the tasks listed.

Task Summary
● In /etc/init.d, copy the lp script to a file called banner.
Change the content of banner according to the instructions in step
3 of the tasks. Make banner executable and test that it works with
the start and stop arguments. In /etc/rc2.d, create a hard
link to /etc/init.d/banner called S22banner. In
/etc/rcS.d, create a hard link to /etc/init.d/banner called
K99banner.

● Reboot the system and verify that S22banner runs. Shut down the
system to run level S and verify that K99banner runs. Change
back to run level 3. Make a backup copy of /etc/system. Check if
any instances of the st driver are loaded. Modify /etc/system to
forceload the st driver. Reboot the system and verify that st driver
instances are loaded.

● Edit /etc/system to exclude the main disk driver for you system
(either dad or sd). Shut down the system to run level 0 and attempt
to boot it. Make note of what happens. Boot the system using the -
a option to the boot command. Use your backup of /etc/system
as required. Replace /etc/system with your backup when fin-
ished and reboot the system.

13-30 Solaris 8™ Operating Environment System Administration I

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
Tasks
1. Log in as root and open a terminal window. Change directory to
/etc/init.d. Create a copy of the lp script and call it banner.
# cd /etc/init.d
# cp lp banner

2. In /etc/init.d, use vi to edit the banner script. Replace the

line (line 16) that reads:
[ -f /usr/lib/lpsched ] && /usr/lib/lpsched

with a line that reads:

echo ""; /usr/bin/banner "SA-238 up"; echo""

Replace the line (line 20) that reads:

[ -f /usr/lib/lpshut ] && /usr/lib/lpshut

With a line that reads:

echo ""; /usr/bin/banner "SA-238 dwn"; echo""

3. Make the banner script executable and verify that it runs with
both the start and stop arguments.
# chmod a+x banner
# ./banner start
# ./banner stop

4. Change directory to /etc/rc2.d. Create a hard link called

S22banner that points to the same data as
/etc/init.d/banner.
# cd /etc/rc2.d
# ln /etc/init.d/banner S22banner

5. Change directory to /etc/rcS.d. Create a hard link called

K99banner that points to the same data as
/etc/init.d/banner.
# cd /etc/rcS.d
# ln /etc/init.d/banner K99banner

System Boot Process 13-31

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
6. Reboot the system and watch for the output of the script you just
installed. Does the startup message from S22banner display?
# init 6

______

7. Login as root and open a terminal window. Use init to change

to run level S. Does the shutdown message from K99banner
display?
# init S

______

8. Enter the password for root in order to login at the command

line. Change to run level 3.
# init 3

9. Login as root and open a terminal window. Change directory to

/etc.
# cd /etc

10. Make a backup copy of /etc/system and name the back file
system.orig.
# cp system system.orig

11. If your system uses a SCSI tape device, perform the following:

a. Log in as root and open a terminal window. Use the

prtconf command to list instances of the st driver currently
loaded.
# prtconf | grep “st, instance”

How many instances are reported? ______

b. Edit the /etc/system file so it includes the following line:

forceload: drv/st

Then, reboot the system.

# init 6

13-32 Solaris 8™ Operating Environment System Administration I

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
c. Log in as root and open a terminal window. Again list
instances of the st driver currently loaded.
# prtconf | grep “st, instance”

How many instances are reported? ______

12. Edit /etc/system so it excludes the main disk driver for your
system.

On systems using SCSI disks add the following:

exclude: drv/sd

On systems using IDE disks add the following:

exclude: drv/dad

13. Shut down the system to run level 0, and then attempt to boot it
again.
# shutdown -y -i0 -g0

(shutdown messages)
ok boot

What happened?

_______________________________________________

14. Use the boot -a command to boot the system and supply the
name of your backup file called etc/system.orig. Enter
carriage returns to accept the default values for all other boot
parameters. Example:
ok boot -a
Enter filename [kernel/sparcv9/unix]: <Return>
Enter default directory for modules [/platform...]:
<Return>
Name of system file [etc/system]: etc/system.orig
root filesystem type [ufs]: <Return>
Enter physical name of root device [/...]: <Return>

15. Log in as root and open a terminal window. Copy

/etc/system.orig to /etc/system. Reboot the system.
# cd /etc
# cp system.orig system
# init 6

System Boot Process 13-33

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
Exercise: The Boot Process

Exercise Summary
Discussion – Take a few minutes to discuss what experiences, issues,
or discoveries you had during the lab exercises.

● Experiences

● Interpretations

● Conclusions

● Applications

13-34 Solaris 8™ Operating Environment System Administration I

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
Exercise: The Boot Process

Task Solutions
6. Reboot the system and watch for the output of the script you just
installed. Does the startup message from S22banner display?

Yes.

7. Login as root and open a terminal window. Use init to change

to run level S. Does the shutdown message from K99banner
display?

Yes.

11. If your system uses a SCSI tape device, perform the following:

a. Log in as root and open a terminal window. Use the

prtconf command to list instances of the st driver currently
loaded.

How many instances are reported? None.

b. Log in as root and open a terminal window. Again list

instances of the st driver currently loaded.

How many instances are reported? The number will vary

depending on how many SCSI controllers are present. You should see
instances 0 through 6 for a system with one controller.

12. Shut down the system to run level 0, and then attempt to boot it
again.

What happened?

The system will be unable to boot. Excluding this driver prevents you
from using the boot disk so long as you use the same /etc/system
file. You must boot using the -a option to be able to supply an alternate
file for /etc/system.

System Boot Process 13-35

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A
 13
Check Your Progress

Before continuing on to the next module, check that you are able to
accomplish or answer the following:

❑ Describe the four phases of the boot process

❑ Identify the directories that contain the kernel and its loadable
modules

❑ Modify the kernel’s configuration file

❑ Describe the eight Solaris Operating Environment run levels

❑ Define a system’s current run level using the who -r command

❑ Explain the purpose of the /etc/inittab file

❑ Describe the steps in the init process to bring a system to

multiuser mode

❑ List the directories that hold the run control scripts used to stop
and start system processes and services.

❑ Describe the steps add a new run control script

❑ Use the following commands to shut down the system: init,

shutdown, halt, poweroff, and reboot

13-36 Solaris 8™ Operating Environment System Administration I

Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services June 2000, Revision A