How to Perform System Boot and Shutdown Procedures for Solaris 10, Part D

Starting Services During Boot

Under SMF, the boot process is much quieter than previous versions of Solaris. This was done to reduce the amount of uninformative "chatter" that might obscure any real problems that might occur during boot.

Some new boot options have been added to control the verbosity of boot. One that you may find particularly useful is -m verbose, which prints a line of information when each service attempts to start up. This is similar to previous versions of Solaris where the boot messages were more verbose.

You can also boot the system using one of the milestones as follows:

boot -m milestone=single-user

The system will boot into single-user mode where only the basic services are started as shown when the svcs command is used to display services.

STATE     STIME    FMRI

disabled  17:10:27 svc:/system/filesystem/local:default

disabled  17:10:27 svc:/system/identity:domain

disabled  17:10:27 svc:/system/sysidtool:net

disabled  17:10:28 svc:/system/cryptosvc:default

disabled  17:10:28 svc:/network/initial:default

disabled  17:10:28 svc:/network/rpc/bind:default

disabled  17:10:28 svc:/system/sysidtool:system

disabled  17:10:28 svc:/milestone/sysconfig:default

Output has been truncated . . . . .

This method of booting is slightly different than using the boot -s command. When the system is explicitly booted to a milestone, exiting the console administrative shell will not transition the system to multi-user mode, as boot -s does. To move to multi-user mode after boot -m milestone=single-user, use the following command:

svcadm milestone milestone/multi-user-server:default

The milestones that can be specified at boot time are

• none
• single-user
• multi-user
• multi-user-server
• all

If you boot a system using one of the milestones and you do not include the -s option, the system will stay in the milestone state that you booted the system in. The system will not go into multi-user state automatically when you press Ctrl+D. You can however, get into the multi-user state by using the following command and all services will be restored:

svcadm milestone all

To boot the system without any milestones, type

boot -m milestone=none

The boot command instructs the svc.startd daemon to temporarily disable all services except for the master restarter named svc:/system/svc/restarter:default and start sulogin on the console. The "none" milestone can be very useful in troubleshooting systems that have failures early in the boot process.

To bring the system back down to single-user mode from multi-user mode, type

svcadm milestone milestone/single-user

The -d option can be used with the previous example to cause svcadm to make the given milestone the default boot milestone, which persists across reboots. This would be the equivalent of setting the default run level in the /etc/inittab file on previous versions of Solaris.

Other options that can be used with svcadm include

• -r—Enables each service instance and recursively enables its dependencies.
• -s—Enables each service instance and then waits for each service instance to enter the online or degraded state. svcadm will return early if it determines that the service cannot reach these states without administrator intervention.
• -t—Temporarily enables or disables each service instance. Temporary enable or disable only lasts until reboot.

SMF Message Logging

In addition to the system logging methods described earlier in this chapter, each service has a log file in the /var/svc/log directory (or the /etc/svc/volatile directory, for services started before the single-user milestone) indicating when and how the system was started, whether it started successfully, and any messages it may have printed during its initialization. If a severe problem occurs during boot, you will be able to log in on the console in maintenance mode, and you can use the svcs command to help diagnose the problem, even on problems which would have caused boot to hang. Finally, the new boot -m boot option allows the system administrator to configure the boot process to be more verbose, printing a simple message when each service starts.

Creating New Service Scripts

Objective: Use Service Management Facility or legacy commands and scripts to control both the boot and shutdown procedures.

As you customize your system, you’ll create custom scripts to start and stop processes or services on your system. The correct procedure for incorporating these scripts into the SMF is as follows:

• Determine the process for starting and stopping your service.
• Establish a name for the service and the category this service falls into.
• Determine whether your service runs multiple instances.
• Identify any dependency relationships between this service and any other services. Practically every service has a dependency so that the service does not startup too soon in the boot process.
• If a script is required to start and stop the process, create the script and place it in a local directory such as /lib/svc/method.
• Create a service manifest file for your service in the /var/svc/manifest/site directory. This XML file describes the service and any dependency relationships. Service manifests are incorporated into the repository either by using the svccfg command or at boot time. See the service_bundle(4) manual page for a description of the contents of the SMF manifests.
• Incorporate the script into the SMF using the svccfg utility.

The following step by step describes the process of setting up and enabling an existing service instance.

STEP BY STEP

3.3 Enable the NFS Server Service

In the following example, I'll configure SMF to share the NFS resources on an NFS server.

1. Log in as root or use a role that includes the Service Management rights profile.
2. The NFS server services are not running as displayed by the following svcs command:

svcs -a| grep -i nfs

The system displays the following information about the NFS services:

disabled  15:47:56 svc:/network/nfs/cbd:default

disabled  15:47:59 svc:/network/nfs/server:default

online    15:48:36 svc:/network/nfs/mapid:default

online    15:48:36 svc:/network/nfs/status:default

online    15:48:37 svc:/network/nfs/nlockmgr:default

online    15:48:44 svc:/network/nfs/client:default

online    15:54:26 svc:/network/nfs/rquota:default

Notice that svc:/network/nfs/server:default is disabled.

3. Set up the required NFS configuration file on the server. To share a file system named /data, I need to configure the /etc/dfs/dfstab file as described in Chapter 9. I add the following line to the NFS server configuration file:

share -F nfs -o rw /data

4. Enable the NFS service as follows:

svcadm enable svc:/network/nfs/server

5. Verify that the NFS server service is running by typing:

svcs -a | grep -i nfs

The system displays the following information:

disabled  15:47:56 svc:/network/nfs/cbd:default

online    15:48:44 svc:/network/nfs/client:default

online    11:22:26 svc:/network/nfs/status:default

online    11:22:26 svc:/network/nfs/nlockmgr:default

online    11:22:27 svc:/network/nfs/mapid:default

online    11:22:28 svc:/network/nfs/server:default

online    11:22:28 svc:/network/nfs/rquota:default

This next step by step describes how to create a new service and incorporate it into the SMF. Taking the time to convert your existing RC scripts to SMF allows them to take advantage of automated restart capabilities that could be caused by hardware failure, unexpected service failure, or administrative error. Participation in the service management facility also brings enhanced visibility with svcs (as well as future-planned GUI tools) and ease of management with svcadm and other Solaris management tools. The task requires the creation of a short XML file and making a few simple modifications to the service RC script. The following step by step will take you through the process.

STEP BY STEP

3.4 Converting an RC Script to SMF

Before I start, I’ll take an existing legacy RC script and place it under SMF control as a service. This script is named /etc/init.d/legacy and has the following entries:

#!/sbin/sh

case "$1" in

‘start’)

  /usr/local/legacyprog

  ;;

‘stop’)

  /usr/bin/pkill -x -u 0 legacyprog

  ;;

*)

  echo "Usage: $0 { start | stop } "

  exit 1

  ;;

esac

exit 0

I’ll move this script to /lib/svc/method/legacyservice.

The most complex part of this procedure is writing the SMF manifest in XML. Currently, these manifests need to be created with an editor, but in the future, expect a GUI-based tool to aid in the creation of the manifest file. The service_bundle(4) man page describes this XML-based file, but you need to be familiar with the XML programming language, and that is beyond the scope of this book. Here’s a copy of my manifest for the service we are going to implement; I named it /var/svc/manifest/site/legacyservice, and I’ll describe the contents of the file in this section.

<?xml version="1.0"?>

<!DOCTYPE service_bundle SYSTEM

"/usr/share/lib/xml/dtd/service_bundle.dtd.1">

<!--

ident "@(#)newservice.xml 1.2 04/09/13 SMI"

-->

<service_bundle type=’manifest’ name=’OPTnew:legacyservice’>

<service

  name=’site/legacyservice’

  type=’service’

  version=’1’>

<single_instance/>

<dependency

  name=’usr’

  type=’service’

  grouping=’require_all’

  restart_on=’none’>

  <service_fmri value=’svc:/system/filesystem/local’ />

</dependency>

<dependent

  name=’newservice’

  grouping=’require_all’

  restart_on=’none’>

  <service_fmri value=’svc:/milestone/multi-user’ />

</dependent>

<exec_method

  type=’method’

  name=’start’

  exec=’/lib/svc/method/legacyservice start’

  timeout_seconds=’30’ />

<exec_method

  type=’method’

  name=’stop’

  exec=’/lib/svc/method/legacyservice stop’

  timeout_seconds=’30’ />

<property_group name=’startd’ type=’framework’>

<propval name=’duration’ type=’astring’ value=’transient’

/>

</property_group>

<instance name=’default’ enabled=’true’ />

<stability value=’Unstable’ />

<template>

  <common_name>

    <loctext xml:lang=’C’>

    New service

    </loctext>

  </common_name>

</template>

</service>

</service_bundle>

Now let's take a closer look at the XML-based manifest file and the steps I took to create it.

1. My file starts out with a standard header. After the header, I specify the name of the service, the type of service, the package providing the service, and the service name as follows:

<?xml version="1.0"?>

<!DOCTYPE service_bundle SYSTEM

"/usr/share/lib/xml/dtd/service_bundle.dtd.1">

<!--

ident "@(#)newservice.xml 1.2 04/09/13 SMI"

-->

<service_bundle type='manifest' name='OPTnew:legacyservice'>

2. I specify the service category, type, name, and version. These categories aren't used by the system, but help the administrator in identifying the general use of the service. These categories types are

application—Higher level applications, such as apache

milestone—Collections of other services, such as name-services

platform—Platform-specific services, such as Dynamic Reconfiguration daemons

system—Solaris system services, such as coreadm

device—Device-specific services

network—Network/Internet services, such as protocols

site—Site specific descriptions

The service name describes what is being provided, and includes both any category identifier and the actual service name, separated by '/'. Service names should identify the service being provided. In this example, the entry I'll make to my manifest file is as follows:

<service

  name='site/legacyservice'

  type='service'

  version='1'>

3. Identify whether your service will have multiple instances. The instance name describes any specific features about the instance. Most services deliver a "default" instance. Some (such as Oracle) may want to create instances based on administrative configuration choices. This service will have a single instance, so I'll make the following entry in the manifest:

<single_instance />

4. Define any dependencies for this service. I added the following entry to the manifest:

<dependency

  name='usr'

  type='service'

  grouping='require_all'

  restart_on='none'>

  <service_fmri value='svc:/system/filesystem/local' />

</dependency>

The first entry states that the legacyservice requires the filesystem/local service.

5. We now need to identify dependents. If I want to make sure that my service is associated with the multi-user milestone and that the multi-user milestone requires this service, I add the following entry to the manifest:

<dependent

   name='testservice'

   grouping=require_all'

   restart_on='none'>

   <service_fmri value='svc:/milestone/multi-user' />

  <dependent>

By having the ability to identify dependents, I'm able to deliver a service that is a dependency of another service (milestone/multi-user) which I don't deliver. I can specify this in my legacyservice manifest without modifying the milestone/multi-user manifest, which I don't own. It's an easy way to have a service run before a Solaris default service.

If all the dependent services have not been converted to SMF, you'll need to convert those too, as there is no way to specify a dependent on a legacy script.

To avoid conflicts, it is recommended that you preface the dependent name with the name of your service. For example, if you're delivering a service (legacyservice) that must start before syslog, use the following entry:

<dependent

 name='legacyservice_syslog'

6. Specify how the service will be started and stopped. SMF interacts with your service primarily by its methods. The stop and start methods must be provided for services managed by svc.startd, and can either directly invoke a service binary or a script which handles care of more complex setup. The refresh method is optional for svc.startd managed services. I'll use the following start and stop methods:

<exec_method

  type='method'

  name='start'

  exec='/lib/svc/method/legacyservice start'

  timeout_seconds='30' />

<exec_method

  type='method'

  name='stop'

  exec='/lib/svc/method/legacyservice stop'

  timeout_seconds='30' />

Timeouts must be provided for all methods. The timeout should be defined to be the maximum amount of time in seconds that your method might take to run on a slow system or under heavy load. A method which exceeds its timeout will be killed. If the method could potentially take an unbounded amount of time, such as a large file system fsck, an infinite timeout may be specified as '0'.

7. Identify the service model—will it be started by inetd or svc.startd? My service will be started by svc.startd. svc.startd provides three models of service, which are

Transient services—These are often configuration services, which require no long-running processes to provide service. Common transient services take care of boot-time cleanup or load configuration properties into the kernel. Transient services are also sometimes used to overcome difficulties in conforming to the method requirements for contract or wait services. This is not recommended and should be considered a stopgap measure.

Wait services—These services run for the lifetime of the child process, and are restarted when that process exits.

Contract services—These are the standard system daemons. They require processes which run forever once started to provide service. Death of all processes in a contract service is considered a service error, which will cause the service to restart.

The default service model is contract, but may be modified. For this example, I'm going to start the service with svc.startd. As a transient service, it will be started once and not restarted by adding the following lines to the manifest:

<property_group name='startd' type='framework'>

<propval name='duration' type='astring' value='transient'

/>

</property_group>

8. The next step is to create the instance name for the service by making the following entry:

<instance name='default' enabled='true' />

9. Finally, create template information to describe the service providing concise detail about the service. I'll assign a common name in the C locale. The common name should

Be short (40 characters or less)

Avoid capital letters aside from trademarks like Solaris

Avoid punctuation

Avoid the word service (but do distinguish between client and server)

I make the following entry in the manifest to describe my service as "New service":

<template>

  <common_name>

    <loctext xml:lang='C'>

    New service

    </loctext>

  </common_name>

</template>

10. Once the manifest is complete, is a good idea to verify the syntax using the xmllint program as follows:

xmllint --valid /var/svc/manifest/site/legacyservice

The xmllint program will parse the XML file and identify any errors in the code before you try to import it into SMF. The scvcfg program also can validate your file as follows, but the output is not as verbose as the xmllint command:

svccfg validate /var/svc/manifest/site/legacyservice

11. Once you've validated the syntax of your XML file, the new service needs to be imported in SMF by issuing the svccfg command as follows:

svccfg import /var/svc/manifest/site/legacyservice

12. The service should now be visible using the svcs command as follows:

# svcs legacyservice

STATE   STIME FMRI

-    svc:/site/legacyservice:default

13. You can also see which services the legacyservice depends on by using the svcs -d command as follows:

svcs -d legacyservice

STATE    STIME  FMRI

online   Sep_20 svc:/system/filesystem/local:default

14. As a final step, enable the service using the svcadm command as follows:

svcadm -v enable legacyservice

svc:/site/legacyservice:default enabled.

15. At any time, I can view the properties of a service using the svccfg command as follows:

svccfg -v -s legacyservice

The system responds with the following prompt:

svc:/site/legacyservice> 

Use the listprop subcommand at the svccfg prompt to list the service properties:

svc:/site/legacyservice> listprop

usr                                     dependency

usr/entities                    fmri  svc:/system/filesystem/local

usr/grouping                    astring require_all

usr/restart_on                          astring none

usr/type                                astring service

general                                 framework

general/entity_stability  astring Unstable

general/single_instance   boolean true

dependents                      framework

dependents/newservice    astring svc:/milestone/multi-user

startd                                  framework

startd/duration                 astring transient

start                                   method

start/exec                      astring "/lib/svc/method/legacyservice start"

start/timeout_seconds    count 30

start/type                      astring method

stop                                    method

stop/exec                       astring "/lib/svc/method/legacyservice stop"

stop/timeout_seconds     count 30

stop/type                       astring method

tm_common_name                          template

tm_common_name/C                ustring "New service"

svc:/site/legacyservice>

Legacy Services

Objective: Use Service Management Facility or legacy commands and scripts to control both the boot and shutdown procedures.

Solaris 10 still supports legacy RC scripts referred to as legacy services, but you will notice that the /etc/inittab file used by the init daemon has been significantly reduced. In addition, RC scripts that were located in the /etc/init.d directory and linked to the /etc/rc#.d directory have also been reduced substantially. For many of the scripts that remain, simply run the svcadm command to start the appropriate service.

SMF-managed services no longer use RC scripts or /etc/inittab entries for startup and shutdown, so the scripts corresponding to those services have been removed. In future releases of Solaris, more services will be managed by SMF, and these directories will become less and less populated. RC scripts and /etc/inittab entries that manage third-party–provided or locally developed services will continue to be run at boot. These services may not run at exactly the same point in boot as they had before the advent of SMF, but they are guaranteed to not run any earlier—any services which they had implicitly depended on will still be available.

For those readers who are experienced on Solaris versions prior to Solaris 10, you are accustomed to starting and stopping services via rc scripts. For instance, to stop and start the sshd daemon, you would type:

/etc/init.d/sshd stop

/etc/init.d/sshd start

In SMF, the correct procedure to start sshd is to type

svcadm enable -t network/ssh:default

To temporarily stop sshd, you would type

svcadm disable -t network/ssh:default

Or simply type

svcadm restart network/ssh:default

to stop and restart the sshd daemon.

Prior to Solaris 10, to send a HUP signal to the ssh daemon, we would have typed

kill -HUP ´cat /var/run/sshd.pid´

In Solaris 10, the correct procedure is to type

svcadm refresh network/ssh:default

Using the Run Control Scripts to Stop or Start Services

Although it is recommended that you use SMF to start and stop services as described in the previous section, "Creating New Service Scripts," functionality still exists to allow the use of run control scripts to start and stop system services at various run levels. Run control scripts were used in previous versions of Solaris to start and stop system services before SMF was introduced.

A run level is a system state (run state), represented by a number or letter that identifies the services and resources that are currently available to users. The who -r command can still be used to identify a systems run state as follows:

who -r

The system responds with the following indicating that run-level 3 is the current run state:

.  run-level 3 Aug 4 09:38  3  1 1

Since the introduction of SMF in Solaris 10, we now refer to these run states as milestones, and Table 3.26 describes how the legacy run states coincide with the Solaris 10 milestones.

Table 3.26 The System Run States

Run State (milestone)

Description

0

Stops system services and daemons. Terminates all running processes. Unmounts all file systems.

S, s (single-user)

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. Only critical file systems are mounted and accessible. 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 (multi-user)

Normal multiuser operation, without network file systems (NFSs) shared: directories; locks interfaces and starts processes; starts the con daemon; cleans up the uucp tmp files; starts the lp system; and starts the sendmail daemon and syslog.

3 (multi-user-server)

Normal multi-use operation of a file server, with NFSs shared. Completes all the tasks in run state 2 and starts the NFS daemons.

4

Alternative multi-user 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.

To support legacy applications that still use them, run control scripts have been carried over from Solaris 9. With run control scripts, each init state (milestone) 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 run state. These rc scripts are as follows:

• rc0
• rc1
• rc2
• rc3
• rc5
• rc6
• rcS

Run Control Scripts

Solaris startup scripts can be identified by their rc prefix or suffix, which means run control.

You can still use the init command to transition to between the various run states. The init daemon will simply pass the required run state to the svc.startd daemon for execution.

The SMF will execute 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 state. For example, /etc/rc3.d contains files that are used to start and stop processes for run state 3.

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. For example, the /sbin/rc0 script runs the scripts located in the /etc/rc0.d directory. The /sbin/rc# script will pass 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.

All run control scripts are also located in the /etc/init.d directory, and all scripts must be /sbin/sh scripts. These files are hard linked to corresponding run control scripts in the /etc/rc<n>.d directories.

These run control scripts can also be run individually to start and stop services. 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 NFS services by typing /etc/init.d/nfs.server start and pressing Enter. If you notice, however, many of these RC scripts simply have svcadm commands embedded in them to perform the task of stopping and starting the service.

In addition to the svcs -p command, you can still 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

If you add a script to the run control directories, you put the script in the /etc/init.d directory and create a hard 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.5.

STEP BY STEP

3.5 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/S99program

 # ln /etc/init.d/program /etc/rc0.d/K01program

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/K01program

389928 -rwxr--r-- 3 root  sys   69 Oct 26 23:31 /etc/rc2.d/S99program

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 to prefix the filename with an underscore. Only files beginning with uppercase prefixes of S or K are run. For example, you could change S99mount to _S99mount to disable the script.

System Shutdown

Objective: Complete a system shutdown.

• Interrupt a hung system.
• Given a scenario involving a hung system, troubleshoot problems and deduce resolutions.

Solaris has been designed to run continuously—7 days a week, 24 hours a day. Occasionally, however, you need to shut down the system to carry out administrative tasks. Very seldom, an application might cause the system to go awry, and the operating system must be stopped to kill off runaway processes, and then be restarted.

You can shut down the system in a number of ways, using various Unix commands. With Solaris, taking down the operating system in an orderly fashion is important. When the sys tem boots, several processes are started; they must be shut down before you power off the system. In addition, information that has been cached in memory and has not yet been written to disk will be lost if it is not flushed from memory and saved to disk. The process of shutting down Solaris involves shutting down processes, flushing data from memory to the disk, and unmounting file systems.

Improper Shutdown Can Corrupt Data

Shutting down a system improperly can result in loss of data and the risk of corrupting the file systems.

Protecting Against Power Loss

To avoid having your system shut down improperly during a power failure, you should use an uninterruptible power supply (UPS) that is capable of shutting down the system cleanly before the power is shut off. Be sure to follow the UPS manufacturer’s recommendations for maintenance to eliminate the risk of the UPS becoming the cause of an improper shutdown.

Commands to Shut Down the System

When you’re preparing to shut down a system, you need to determine which of the following commands is appropriate for the system and the task at hand:

• /usr/sbin/shutdown
• /sbin/init
• /usr/sbin/halt
• /usr/sbin/reboot
• /usr/sbin/poweroff
• Stop+A or L1+A

Aborting the Operating System

Using the Stop+A key sequence (or L1+A) abruptly breaks execution of the operating system and should be used only as a last resort to restart the system.

The first three commands—/usr/sbin/shutdown, /sbin/init, and /usr/sbin/halt—initiate shutdown procedures, kill all running processes, write data to disk, and shut down the system software to the appropriate run level. The /usr/sbin/reboot command does all these tasks as well, and it then boots the system back to the state defined as initdefault in /etc/inittab. The /usr/sbin/poweroff command is equivalent to init state 5.

The /usr/sbin/shutdown Command

You use the shutdown command to shut down a system that has multiple users. The shutdown command sends a warning message to all users who are logged in, waits for 60 seconds (by default), and then shuts down the system to single-user state. The command option -g lets you choose a different default wait time. The -i option lets you define the init state to which the system will be shut down. The default is S.

The shutdown command performs a clean system shutdown, which means that all system processes and services are terminated normally, and file systems are synchronized. You need superuser privileges to use the shutdown command.

When the shutdown command is initiated, all logged-in users and all systems mounting resources receive a warning about the impending shutdown, and then they get a final message. For this reason, the shutdown command is recommended over the init command on a server with multiple users.

Sending a Shutdown Message

When using either shutdown or init, you might want to give users advance notice by sending an email message about any scheduled system shutdown.

The proper sequence of shutting down the system is described in Step by Step 3.6.

STEP BY STEP

3.6 Shutting Down a System

1. As superuser, type the following to find out if users are logged in to the system:

# who

2. A list of all logged-in users is displayed. You might want to send an email message or broadcast a message to let users know that the system is being shut down.
3. Shut down the system by using the shutdown command:

# shutdown -i<init-state> -g<grace-period> -y

Table 3.27 describes the options available for the shutdown command.

Table 3.27 Options for the shutdown Command

Option

Description

-i<init-state>

Brings the system to an init state that is different from the default, S. The choices are 0, S, 1, 2, 5, and 6.

-g<grace-period>

Indicates a time (in seconds) before the system is shut down. The default is 60 seconds.

-y

Continues to shut down the system without intervention; otherwise, you are prompted to continue the shutdown process after 60 seconds. If you use the shutdown -y command, you are not prompted to continue; otherwise, you get the message Do you want to continue? (y or n).

The /sbin/init Command

You use the init command to shut down a single-user system or to change its run level. The syntax is as follows:

init <run-level>

<run-level> is any run level described in Table 3.21. In addition, <run-level> can be a, b, or c, which tells the system to process only /etc/inittab entries that have the a, b, or c run level set. These are pseudo-states, which can be defined to run certain commands but which do not cause the current run level to change. <run-level> can also be the keyword Q or q, which tells the system to reexamine the /etc/inittab file.

You can use init to place the system in power-down state (init state 5) or in single-user state (init state 1). For example, to bring the system down to run level 1 from the current run level, you type the following:

init 1

The system responds with this:

svc.startd: Changing to state 1.

svc.startd: Killing user processes: done.

svc.startd: The system is ready for administration.

Requesting System Maintenance Mode

(See /lib/svc/share/README for more information.)

Root password for system maintenance (control-d to bypass):<enter root password>

single-user privilege assigned to /dev/console.

Entering System Maintenance Mode

Aug 4 09:18:13 su: ‘su root’ succeeded for root on /dev/console

Sun Microsystems Inc. SunOS 5.10  Generic January 2005

The telinit Command

The /etc/telinit command is the same as the init command. It is simply a link to the /usr/sbin/init command.

The /usr/sbin/halt Command

You use the halt command when the system must be stopped immediately and it is acceptable not to warn current users. The halt command shuts down the system without delay and does not warn other users on the system of the shutdown.

The /usr/sbin/reboot Command

You use the reboot command to shut down a single-user system and bring it into multi-user state. reboot does not warn other users on the system of the shutdown.

The Solaris reboot, poweroff, and halt commands stop the processor and synchronize the disks, but they perform unconditional shutdown of system processes. These commands are not recommended because they do not shut down any services and unmount any remaining file systems. They will, however, attempt to kill active processes with a SIGTERM, but the services will not be shut down cleanly. Stopping the services without doing a clean shutdown should only be done in an emergency or if most of the services are already stopped.

The speed of such a reboot is useful in certain circumstances, such as when you’re rebooting from the single-user run state. Also, the capability to pass arguments to OpenBoot via the reboot command is useful. For example, this command reboots the system into run level s and reconfigures the device tables:

reboot -- -rs

The /usr/sbin/poweroff Command

The poweroff command is equivalent to the init 5 command. As with the reboot and halt commands, the poweroff command synchronizes the disks and immediately shuts down the system, without properly shutting down services and unmounting all file systems. Users are not notified of the shutdown. If the hardware supports it, the poweroff command also turns off power.

The init and shutdown Commands

Using init and using shutdown are the most reliable ways to shut down a system because these commands shutdown services in a clean orderly fashion and shut down the system with minimal data loss. The halt, poweroff, and reboot commands do not shutdown services properly and are not the preferred method of shutting down the system.

Stopping the System for Recovery Purposes

Occasionally, a system might not respond to the init commands described earlier in this chapter. A system that doesn’t respond to anything, including reboot or halt, is called a "crashed" or "hung" system. If you try to use the commands discussed in the preceding sections but get no response, on non-USB style keyboards, you can press Stop+A or L1+A to get back to the boot PROM. (The specific Stop key sequence depends on your keyboard type.) On terminals connected to the serial port, you can press the Break key, as described in the section "Accessing the OpenBoot Environment," earlier in this chapter.

Some OpenBoot systems provide the capability of commanding OpenBoot by means of pressing a combination of keys on the system’s keyboard, referred to as a keyboard chord or key combination. These keyboard chords are described in Table 3.28. When issuing any of these commands, you press the keys immediately after turning on the power to your system, and you hold down the keys for a few seconds until the keyboard light-emitting diodes (LEDs) flash. It should be noted, however, that these keyboard chords only work on non-USB keyboards and not USB style keyboards.

Table 3.28 Keyboard Chords

Command

Description

Stop

Bypasses the POST. This command does not depend on the security mode. (Note that some systems bypass the POST as a default; in such cases, you use Stop+D to start the POST.)

Stop+A

Interrupts any program currently running and puts the system at the OpenBoot prompt, ready to accept OpenBoot PROM commands.

Stop+D

Enters diagnostic mode (sets the diag-switch? variable to true).

Stop+F

Enters Forth on the ttya port instead of probing. Uses fexit to continue with the initialization sequence. This chord is useful if hardware is broken.

Stop+N

Resets the contents of NVRAM to the default values.

Disabling Keyboard Chords

The commands in Table 3.26 are disabled if PROM security is on. Also, if your system has full security enabled, you cannot apply any of these commands unless you have the password to get to the ok prompt.

To change the default abort sequence on the keyboard, you need to edit the /etc/default/ kbd file. In that file, you can enable and disable keyboard abort sequences, and change the keyboard abort sequence. After modifying this file, you issue the kbd -i command to update the keyboard defaults.

The process of breaking out of a hung system is described in Step by Step 3.7.

Interrupting a Hung System

Step by Step 3.5 describes an objective that is sure to be on the exam. Make sure that you understand each step and the order in which the steps are executed.

STEP BY STEP

3.7 Breaking Out of a Hung System

1. Use the abort key sequence for your system (Stop+A or L1+A).

The monitor displays the ok PROM prompt.

2. Type the sync command to manually synchronize the file systems:

ok sync

The sync procedure synchronizes the file systems and is necessary to prevent corruption. During the sync process, the system will panic, synchronize the file systems, perform a crash dump by dumping the contents of kernel memory to disk, and finally perform a system reset to start the boot process.

3. After you receive the login: message, log in and type the following to verify that the system is booted to the specified run level:

# who -r

4. The system responds with the following:

run-level 3 Jun 9 09:19 3 0 S

Turning Off the Power to the Hardware

Only after shutting down the file systems should you turn off the power to the hardware. You turn off power to all devices after the system is shut down. If necessary, you should also unplug the power cables. When power can be restored, you use the process described in Step by Step 3.8 to turn on the system and devices.

STEP BY STEP

3.8 Turning Off the Power

1. Plug in the power cables.
2. Turn on all peripheral devices, such as disk drives, tape drives, and printers.
3. Turn on the CPU and monitor.