Home > Articles

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.

Pearson IT Certification Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Pearson IT Certification and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Pearson IT Certification products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by Adobe Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.pearsonitcertification.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020