- Introduction
- Booting a System
- The OpenBoot Environment
- The OpenBoot Architecture
- The OpenBoot Interface
- Getting Help in OpenBoot
- PROM Device Tree (Full Device Pathnames)
- OpenBoot NVRAM
- OpenBoot Security
- OpenBoot Diagnostics
- OpenBoot PROM Versions
- Booting a System
- The Kernel
- System Run States
- System Shutdown
- Chapter Summary
- Apply Your Knowledge
This chapter is from the book
This chapter is from the book
This chapter is from the book
System Run States
After control of the system is passed to the kernel, the system begins initialization and enters one of eight run states—also called init states—as described in Table 3.21. Because run state 4 is currently not used, only seven usable run states exist.
NOTE
System Run States Run states are sometimes referred to as init states because the init process transitions between run states and you can use the init command to transition between run states. The terms run state, run level, and init state are all used to describe system run states and are interchangeable.
Table 3.21 - The System Run States
|
Run State |
Description |
|
0 |
Stops system services and daemons. Terminates all running processes. Unmounts all file systems. |
|
S, s |
Single-user (system administrator) state. Only root is allowed to log in at the console, and any logged-in users are logged out when you enter this run level. If the system is booted into this run level, only the root file system and the /usr, /var, /proc, /etc/mnttab, and /var/run file systems are mounted. All services except the most basic operating system services are shut down in an orderly manner. |
|
1 |
Single-user (system administrator) state. If the system is booted into this run level, all local file systems are mounted. All services except the most basic operating system services are shut down. |
|
2 |
Normal multiuser operation, without network file systems (NFSs) shared: Sets the time zone variable; mounts the /usr file system; cleans up the /tmp and /var/tmp directories; loads the network interfaces and starts processes; starts the cron daemon; cleans up the uucp tmp files; starts the lp system; and starts the sendmail daemon and syslog. |
|
3 |
Normal multiuser operation of a file server, with NFSs shared. Completes all the tasks in run state 2 and starts the NFS daemons. |
|
4 |
Alternative multiuser state (currently not used). |
|
5 |
Power-down state. Shuts down the system so that it is safe to turn off power to the system. If possible, automatically turns off system power on systems that support this feature. |
|
6 |
Reboot state. |
NOTE
Run Level 1 Versus Run Level S The difference between run level 1 and run level S (or s) is that in run level 1, all local file systems are mounted. If you issue init S or init 1, user sessions are terminated.
The init state in which the system is running defines the services and resources that are available to users. When preparing to perform a system administration task, you need to determine which init state is appropriate for the task. You can use Table 3.22 to determine what init state to use for a particular task. A system can run in only one init state at a time.
Table 3.22 - The Defined System init States
|
init State |
When to Use It |
|
0 |
To shut down the system so that it is safe to turn off the power (system administrator state). |
|
S, s |
Used when the system administrator is performing administrative tasks that require all users to be logged out of the system, such as when performing level 0 backups or repairing file systems. Any function that requires the system administrator to be in single-user mode should be run at this init level, the single-user (system administrator) state. |
|
1 |
Used when the system administrator is performing administrative tasks and does not want additional users to log in to the system but wants all local file systems mounted, such as when performing backups and file system checks on file systems currently not in use by logged-in users. This is the single-user (system administrator) state. |
|
2 |
For normal operations when sharing of local file systems is not required. Multiple users can log in and access all the file systems. All daemons are running except NFS server. You should use this init state when you want to ensure that remote hosts cannot mount local file systems (read more about NFS in Chapter 8, "The Solaris Network Environment") or when you want the syslogd daemon to be inactive. |
|
3 |
For normal operations, with NFS resource sharing available. This is the normal init state on most systems. |
|
4 |
Alternative multiuser state (currently not used). |
|
5 |
To shut down the operating system so that it is safe to turn off power to the system. All users are logged off the system, and the operating system services are stopped in an orderly manner. When this power-down is complete, it's safe to turn off power to the system and all peripherals. If supported by the system hardware, the power to the system is automatically turned off. |
|
6 |
To shut down the system to run level 0 and then reboot to multiuser level (or whatever level is the default in the inittab file). |
To check which init state the system is currently running, you type the following:
who –r
The system responds with the following:
. run-level 3 Jul 18 18:09 3 0 S
This indicates that the system is currently running at init state 3.
swapper
The first task for the kernel is to start the swapper process. The swapper process is the part of the kernel that schedules all other processes. swapper has a process ID of 0 and is named sched. Its first job is to start up the init process.
NOTE
What Happened to swapper? In versions of Solaris prior to Solaris 9, this process is called swapper but has now been renamed sched (scheduler).
The init Phase
Control boot processes using associated directories, scripts, and commands.
The /sbin/init command generates processes to set up the system based on the directions in /etc/inittab. The init process is the parent of all other processes. It examines the contents of the /etc/inittab file to determine the order for starting up other processes and what to do when one of these processes ends. 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 the process is terminated
What actions to take when the system enters a new run level
Each entry in the /etc/inittab file has the following fields:
id:runlevel:action:process
Table 3.23 provides a description of each field.
Table 3.23 - Fields in the inittab File
|
Field |
Description |
|
id |
A unique identifier |
|
rstate |
The run level(s) |
|
action |
How the process is to be run |
|
process |
The name of the command to execute |
The following example shows a 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
When the system is first booted, init starts all processes labeled sysinit in the /etc/inittab file. The initdefault entry in /etc/inittab identifies the default run level. In this example, the default is run level 3 (multiuser mode with network file sharing). The init daemon runs each process associated with this run level (that is, each entry that has a 3 in its rstate field). Each process is run using the entry from the action field. The action field can have one of the values listed in Table 3.24.
Table 3.24 - inittab action Field Values
|
Field |
Description |
|
sysinit |
Executes the process before init tries to access the console via the console prompt. init waits for the completion of the process before it continues to read the inittab file. |
|
powerfail |
Indicates that the system has received a powerfail signal. |
|
wait |
Waits for the command to be completed before moving to the next entry that contains the same run level. |
|
respawn |
Specifies that init should restart the process if it dies. |
rc Scripts
Each init state has a corresponding series of run control scripts—which are referred to as rc scripts and are located in the /sbin directory—to control each init state. These rc scripts are as follows:
rc0
rc1
rc2
rc3
rc5
rc6
rcS
NOTE
Run Control Scripts Many of the Solaris startup scripts can be identified by their rc prefix or suffix, which means run control.
The init process executes the /sbin/rc<n> scripts, which in turn execute a series of other scripts that are located in the /etc directory. For each rc script in the /sbin directory, a corresponding directory named /etc/rc<n>.d contains scripts to perform various actions for that run level. For example, /etc/rc2.d contains files that are used to start and stop processes for run level 2.
NOTE
/etc/init.d Although the scripts appear as files in each directory, the rc<n>.d directories contain hard links to the /etc/init.d directory. On other Unix systems, startup scripts are sometimes found in /sbin/rc<n>.d and in /etc/rc<n>.d directories. Links were put into Solaris so that users who are accustomed to other flavors of Unix (HP-UX, SunOS, and so on) can locate the startup files easily. In addition, any scripts they might have ported over that reference these startup files are compatible, without modification. Also, by putting all the scripts in one location, /etc/init.d, it's convenient to find the script needed to start or stop a particular function without searching through all the /etc/rc<n>.d directories.
All run control scripts are also located in the /etc/init.d directory, and all scripts must be /sbin/sh scripts. These files are linked to corresponding run control scripts in the /etc/rc<n>.d directories.
The following is a list of the default scripts located in /etc/rc2.d, which are put there when the operating system is installed:
ls /etc/rc2.d K03samba S05RMTMPFILES S72autoinstall S80spc K03sshd S10lu S72directory S85power K06mipagent S20sysetup S72inetsvc S88sendmail K07dmi S21perf S72slpd S88utmpd K07snmpdx S30sysid.net S73cachefs.daemon S89PRESERVE K16apache S40llc2 S73nfs.client S89bdconfig K21dhcp S42ncakmod S74autofs S90wbem K27boot.server S47pppd S74syslog S92volmgt K28kdc S69inet S74xntpd S93cacheos.finish K28kdc.master S70uucp S75cron S94ncalogd K28nfs.server S71ldap.client S75savecore S95svm.sync README S71rpc S76nscd S99audit S01MOUNTFSYS S71sysid.sys S80lp S99dtlogin
As you'll learn in the section "Adding Scripts to the Run Control Directories," later in this chapter, you can add customized scripts to this directory. The /etc/rc<n>.d scripts are always run in ASCII sort order shown by the ls command and have names of this form:
[K,S][#][filename]
A file that begins with K is referred to as a stop script and is run to terminate (kill) a system process. A file that begins with S is referred to as a start script and is run to start a system process. Each of these start and stop scripts is called by the appropriate /sbin/rc# script, which passes the argument start or stop to each script, based on their prefix and whether the name ends in .sh. There are no arguments passed to scripts that end in .sh. The actions of the different run-control-level scripts are summarized in the following lists.
The /sbin/rc0 script runs the /etc/rc0.d scripts, which do the following:
Stop system services and daemons.
Terminate all running processes.
Unmount all file systems.
The /sbin/rcS script runs the /etc/rcS.d scripts to bring the system up to single-user mode and to do the following:
Establish a minimal network.
Mount /usr, if necessary.
Set the system name.
Check the / and /usr file systems.
Mount pseudo file systems (/proc and /dev/fd).
Rebuild the device entries (for reconfiguration boots).
Check and mount other file systems to be mounted in single-user mode.
init state S is similar to run level 1, except that in init state S all local file systems get mounted and are accessible.
TIP
Keeping Users Off the System You should use the init state S run level to perform system administration tasks when you want to ensure that other users cannot log in and access the system.
The /sbin/rc1 script runs the /etc/rc1.d scripts and does the following:
Stops system services and daemons except for the most basic operating system services
Enables all file systems to be available and allows any logged-in users to remain logged in
Brings up the system in single-user mode
Performs initial system startup or final system shutdown for a Solaris Live Upgrade.
The /sbin/rc2 script sets the TIMEZONE variable, runs the /etc/rc2.d scripts, and does the following:
Mounts all file systems
Enables disk quotas if at least one file system was mounted with the quota option
Saves editor temporary files in /usr/preserve
Removes any files that are in the /tmp directory
Configures system accounting
Configures the default router
Sets the Network Information Services (NIS) domain
Sets the ifconfig netmask
Reboots the system from the installation media or a boot server if either /.PREINSTALL or /AUTOINSTALL exists
Starts inetd, rpcbind, and named, if appropriate
Starts the Kerberos client-side daemon (kerbd)
Starts NIS daemons (ypbind) and Network Information Services Plus (NIS+) daemons (rpc.nisd), if appropriate
Starts keyserv
Starts statd, lockd, xntpd, vold, and utmpd
Mounts all NFS entries
Starts automount
Starts cron
Starts the lp daemons
Starts the sendmail daemon
Starts the name service cache daemon (nscd)
Starts syslog
The /sbin/rc3 script runs the /etc/rc3.d scripts and does the following:
Cleans up sharetab
Starts nfsd
Starts mountd
Starts the master Simple Network Message Protocol (SNMP) agent, snmpdx, and the Solstice Enterprise Agents
Starts rarpd, rpld, and rpc.bootparamd if the system is a boot server
The /sbin/rc5 and /sbin/rc6 scripts run the /etc/rc0.d scripts and do the following:
Kill all active processes.
Unmount all file systems.
Using the Run Control Scripts to Stop or Start Services
The advantage of having individual scripts for each run level is that you can run these scripts individually to turn off processes in Solaris without rebooting or changing init states.
For example, you can turn off NFS server functionality by typing /etc/init.d/nfs.server stop and pressing Enter. After you have changed the system configuration, you can restart the functionality by typing /etc/init.d/nfs.server start and pressing Enter.
You can use the pgrep command to verify whether a service has been stopped or started:
pgrep -f <service>
The pgrep utility examines the active processes on the system and reports the process IDs of the processes. See Chapter 5, "Managing System Processes," for details on this command.
Adding Scripts to the Run Control Directories
When you add a script to the run control directories, you put the script in the /etc/init.d directory and create a link to the appropriate rc<n>.d directory. You need to assign appropriate numbers and names to the new scripts so that they will be run in the proper ASCII sequence, as described in the previous section.
To add a new run control script to a system, follow the process in Step by Step 3.2.
Step by Step 3.2: Adding a Run Control Script
-
Become the superuser.
-
Add the script to the /etc/init.d directory:
# cp <filename> /etc/init.d # cd /etc/init.d # chmod 744 <filename> # chown root:sys <filename>
-
Create links to the appropriate rc<n>.d directory:
# ln <filename> /etc/rc2.d/S<nnfilename> # ln <filename> /etc/rc<n>.d/K<nnfilename>
-
Use the ls command to verify that the script has links in the specified directories:
# ls –li /etc/init.d/*<filename> /etc/rc?.d/[SK]*<filename>
The following example creates an rc script named program that starts up at run level 2 and stops at run level 0. Note the use of hard links versus soft links:
# cp program /etc/init.d # cd /etc/init.d # chmod 744 program # chown root:sys program # ln /etc/init.d/program /etc/rc2.d/S100program # ln /etc/init.d/program /etc/rc0.d/K100program
You can verify the links by typing this:
# ls -li /etc/init.d/*program /etc/rc?.d/[SK]*program
The system displays the following:
389928 -rwxr--r-- 3 root sys 69 Oct 26 23:31 /etc/init.d/program 389928 -rwxr--r-- 3 root sys 69 Oct 26 23:31 /etc/rc0.d/K77program 389928 -rwxr--r-- 3 root sys 69 Oct 26 23:31 /etc/rc2.d/S77program
NOTE
Disabling a Run Control Script If you do not want a particular script to run when the system is entering a corresponding init state, you can change the uppercase prefix (S or K) to some other character; I prefer lowercase (s or k). Only files with uppercase prefixes of S or K are run. For example, you could change S99mount to s99mount to disable the script.