Home > Articles > Operating Systems, Server > Solaris

  • Print
  • + Share This
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

  1. Become the superuser.

  2. 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>
  3. Create links to the appropriate rc<n>.d directory:

    # ln <filename> /etc/rc2.d/S<nnfilename>
    # ln <filename> /etc/rc<n>.d/K<nnfilename>
  4. 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.

  • + Share This
  • 🔖 Save To Your Account