2    Starting Up and Shutting Down the System

Shutting down the system and then restarting it are routine tasks that you may need to perform periodically. On some installations, it is important to keep the system running and available at all times, and to shut down intentionally only for scheduled maintenance or software upgrades.

Usually, you can shut down the system easily and with minimal disruption to system users. Occasionally, you must shut down the system rapidly, causing a moderate degree of disruption to users. Under some circumstances (that are out of your control), the system shuts itself down suddenly, causing substantial disruption to users.

You should develop a site-specific operations manual to define your:

This chapter contains the following information:

2.1    Overview of Shutdown and Booting

Shutting down a system requires root (superuser) privileges. Depending on the system configuration, there are several options available for intentionally shutting down and rebooting the system.

2.1.1    Shutdown Methods

A system can be shut down automatically or manually. The following shutdown methods and utilities are available:

Note that the Shutdown icon in the CDE Application Manager - DailyAdmin folder invokes the SysMan Menu task named Shutdown the system. In this release, dxshutdown has been moved to an obsolete interfaces subset and is replaced by the SysMan Menu task.

2.1.2    Boot Methods

Booting the operating system is performed from the system's console firmware. When a system is powered on, the symbol >>> indicates the console prompt. At this prompt, you enter commands or set system configuration variables such as variables that control what happens when a system is booted. Throughout this chapter, this symbol is referred to as the console prompt. The console is sometimes called the System Reference Manual (SRM) console or the firmware console. Refer to the Owner's Manual that came with your system for information on the commands you can enter at the console prompt.

You can boot a system as follows:

2.1.3    Related Documentation

The following documentation contains information that is relevant to system shutdowns and reboots:

This System Administration guide also contains the following topics of relevance to planning and managing shut downs and error recovery:

2.1.4    System Files

The following system files are used during boot and shutdown operations:

2.1.5    Related Utilities

The following utilities are also used during the boot operation

2.2    Understanding the Boot Operation

When you boot the operating system, you initiate a set of tasks that the system must perform to operate successfully. The system is vulnerable during startup because it is loading the kernel into memory and initializing routines that it depends on for operation. Consequently, you should understand what is happening during the system boot operations, and be prepared to respond if problems occur. Although certain boot operations are dependent on the hardware, some features apply to all systems, as described in the following sections.

2.2.1    Booting Automatically or Manually

The system always boots either automatically or manually. In an automatic boot, the system controls the entire operation. When you boot the system to multiuser mode, or shut down the system with the reboot flag, or when the system panics and recovers, you are relying on an automatic boot. With an automatic boot, the system begins the initialization process and continues until completion or failure.

Manual intervention may be required if the automatic boot fails for some reason, for example, if the fsck command fails.

In a manual boot, the system controls the initial operation, turns control of the procedure over to you, then reinstates control to complete the operation. When you boot the system to single-user mode, you are relying on a manual boot. In an automatic or a manual boot, the operation either succeeds or fails:

2.2.2    Booting to Single-User or Multiuser Mode

The system boots to either single-user or multiuser mode.

Because the init operation does not invoke the startup script prior to turning control over to you, the root file system is mounted read only. Startup of the network and other daemons does not occur, file checking and correction are not enabled, and other operations necessary for full system use are not automatically available to you.

Usually you boot to single-user mode to perform specific administrative tasks that are best accomplished without the threat of parallel activity by other users. You perform these tasks manually before exiting from the Bourne shell. For example, you might check new hardware, mount and check aberrant file systems, change disk partitions, or set the system clock. When you finish your work, you return control to the system, and init continues with its startup tasks and boots to multiuser mode.

In a boot to multiuser mode, the system loads the kernel and moves through various phases such as hardware and virtual memory initialization, resource allocation, scheduling, configuration, module loading, and so on.

At the conclusion of the main initialization tasks (process 0), init (process 1) starts an additional set of tasks that includes reading the /etc/inittab file, acting on instructions found there, and executing the relevant run command scripts. These scripts contain entries that initiate activities such as mounting and checking file systems, removing temporary files, initializing the clock daemon, initializing the network daemon, setting up printer spooling directories and daemons, enabling error logging, and performing other tasks specified within the scripts or in related directories.

At the conclusion of these activities, the system is enabled and accessible to users.

The UNIX operating system allows you to boot an alternate kernel. For example, if you cannot boot your system, you could boot /genvmunix to troubleshoot the problem with your system. You could also boot an alternate kernel to test new drivers or to add options to the existing kernel.

2.3    Preparing to Boot the Installed System

As the system administrator, you set up or encounter various preboot or postshutdown states. The following sections describe and recommend procedures for preparing and initiating a reboot from a variety of system states. The states discussed include the following:

Note

If the system is running in single-user mode and you want to use the ed editor, you must change the protections of the root file system to read-write. At the prompt, enter the following command: 


# mount -u /

2.3.1    Preparing to Boot a Powered-Down System

A system is powered down when the hardware (processor, devices, and peripherals) is turned off. Administrators power down the hardware periodically for routine maintenance or to configure new devices.

If you are preparing to reboot your system from a powered-down state, follow these steps:

  1. Confirm that the hardware and all peripheral devices are connected. Refer to the operator's guide for your hardware for information and instructions for interpreting diagnostic output.

  2. Power up the hardware and peripheral devices. Remember to power up all devices that you powered down earlier. Refer to the operator's manual or the hardware user's guide for instructions on starting your hardware and peripherals.

  3. Confirm that the hardware completed its restart and diagnostic operations. Most hardware provides a diagnostic check as a routine part of its startup operation. Refer to the operator's manual for your hardware for information about your hardware's restart and diagnostic operations.

  4. Wait for the console prompt (>>>). If you have enabled your system to boot automatically when it is powered up, press the halt button to display the console prompt. Refer to the hardware operator's guide for the location of the halt button on your system. See Section 2.4 for more information on setting the default boot action for your system.

  5. Decide which startup mode you want to initiate:

  6. Enter the boot command that corresponds to the desired startup mode.

    Refer to Section 2.4 for the commands and procedures required to boot your system.

2.3.2    Preparing to Boot a Powered-Up, Halted System

When your machine is powered up and enabled but the processor is halted, the system is in console mode. For example, after you shut down the processor with the shutdown -h command or when you run the halt command, your system displays the console prompt (>>>).

When the system displays the console prompt, follow these steps to prepare to boot your system:

  1. Decide which startup mode you want to initiate:

  2. Enter the boot command that corresponds to the desired startup mode.

    Refer to Section 2.4 for the commands and procedures required to boot your system.

2.3.3    Preparing to Transition from Single-User Mode

When your machine is powered up and enabled, the processor is running, and access is limited to root, the system is in single-user mode.

When the system displays the single-user prompt ( # ), follow these steps to prepare to go to multiuser mode:

  1. Decide if you should continue in single-user mode or if you should go to multiuser mode:

  2. When you are ready to go to multiuser mode, press Ctrl/d. Refer to Section 2.4 for the commands and procedures required to boot your system.

2.3.4    Preparing to Boot a Crashed System

If your system crashes and is unable to recover automatically and reboot itself, follow these steps to prepare to boot the system:

  1. Refer to Chapter 12 for information on saving crash dump files, and to check system log files for any information on the causes of the crash.

  2. Confirm that the hardware and all peripheral devices are connected.

  3. Power up the hardware, if necessary. Always power up peripherals and devices before the processor.

  4. Monitor the hardware restart and diagnostic operations. Refer to the operator's guide for your hardware for information and instructions for interpreting diagnostic output:

  5. Decide which startup mode you want to initiate:

  6. Enter the required boot command.

    Refer to Section 2.4 for the commands and procedures required to boot your system.

2.3.5    Preparing to Boot a System Taken Off the Network

If a system is configured to support a network, the boot operation will try to start all the network services that are configured. This will result in the boot process hanging, or taking a very long time to test for the presence of services. If you take a system out of a network without unconfiguring the services, or if a system crashes and has to be disconnected from the network, you will need to perform the additional steps before rebooting the system.

There may also be times when you want to remove a functioning system from a network, For example:

The following procedure assumes that the system is halted at the console prompt:

  1. At the console prompt, set the boot_osflags environment variable to s, to stop the boot at single-user mode as follows: 

    
>>> set boot_osflags s

    You may want to set other variables if you plan to do things such as boot from an alternate disk. See Section 2.4.1 for more information.

  2. Boot the system to single-user (standalone) mode: 

    >>> boot

  3. When the single-user root(#) prompt is displayed, you will need to use an editor. Mount the root file system as follows: 

    # mount -u /

    This enables you to use the ed line editor to edit system files if required, and also to access other commands and utilities. Other editors such as vi are not available at this time, as they do not reside on the root file system (/).

  4. Copy the /etc/rc.config, /etc/rc.config.common and rc.config.site files for safe keeping. For example: 

    # cp /etc/rc.config /etc/orig_rc.config
# cp /etc/rc.config.common /etc/orig_rc.config.common
# cp /etc/rc.config.site /etc/orig_rc.config.site

    Note

    The integrity of the /etc/rc.config, /etc/rc.config.common and /etc/rc.config.site files are important for startup operations and for system configuration. Avoid modifying these files with anything other than the rcmgr command; other subsystems or utilities may not be able to read the files correctly if modifications are not made using rcmgr. Refer to the rcmgr(8) reference page for more information. Refer to the TruCluster documentation for more information on performing boot operations on cluster members.

  5. Use the rcmgr line editor to modify entries in the configuration file that invoke networking services. For example, to test for and turn off Network Information Service (NIS), you would enter the following command: 

    # rcmgr get NIS_CONF
YES
# rcmgr set NIS_CONF NO

    Repeat this operation for each network service that is currently called, such as NTP or NFS.

  6. When you have completed the modifications, halt the system and reset any console environment variables. For example: 

    >>> set boot_osflags a
>>> boot

  7. Your system will now reboot to multiuser mode, without attempting to start any network services.

Note that there might be slight variations in the console commands, depending on the system type. You should consult the hardware documentation for a description of console commands for your processor.

2.4    Booting the System

The command that you use to boot the kernel depends on several factors:

2.4.1    Defining the Console Environment Variables and Using the Boot Commands

To boot your system you need to understand the use of certain console environment variables and their role in affecting the boot process. Table 2-1 lists each of the console environment variables and their associated actions.

Note

This section provides examples of typical console settings. You should refer to the hardware documentation that came with your system. For example, you may be booting UNIX as an alternate operating system to Windows NT and other console commands may be required. See also the information on booting systems in the Installation Guide and Installation Guide -- Advanced Topics.

Table 2-1:  Console Environment Variables

Variable Action
boot_reset When set to on, resets the hardware on boot
boot_osflags A combination of flags used to control the boot loader and kernel
bootdef_dev Identifies the boot device
boot_file Identifies the kernel to boot (on and processors)
cpu_enable Selectively enables particular processors from the console

To prepare the hardware, perform the following steps:

  1. Set the auto_action variable to halt: 

    >>> set auto_action halt

    The previous command will halt the system at the console prompt each time your system is turned on, when the system crashes, or when you press the halt button.

  2. If required for your processor, set the boot_reset variable to on to force the resetting of the hardware before booting: 

    >>> set boot_reset on

  3. If required for your processor, set the time to wait to reset the SCSI device before booting: 

    >>> set scsi_reset 4

  4. Use the following procedure to set the boot_osflags variable and the boot device:

    1. Determine which options to the boot_osflags variable you want. Table 2-2 lists the options.

      Table 2-2:  Options to the boot_osflags Variable

        Action
      a Boot to multiuser mode. (By default, the kernel boots to single-user mode.)
      k Use the kdebug debugger to debug the kernel. Refer to the Kernel Debugging guide for more information.
      d Use full crash dumps. (By default, partial dumps are used.) Refer to Chapter 12 for information on crash dumps.
      i Prompt for the kernel and special arguments. (By default, no questions are asked.)

      The options are concatenated into the boot_osflags variable to achieve the desired effect. For example, to boot to multiuser mode and use full crash dumps, enter: 

      
>>> set boot_osflags ad

      If you want the defaults, clear the variable as shown in the following example: 

      >>> set boot_osflags ""

    2. Determine the unit numbers for your system's devices: 

      
>>> show device

      If you want to boot from the dual SCSI TURBOchannel option card (PMAZB or PMAZC), complete the following steps:

      1. Identify the slot number of the PMAZB or PMAZC option card: 

        >>> show conf

        This command displays the system configuration.

      2. Determine the unit number of your system's devices.

        Use the conf command with the slot number to identify the unit numbers of the devices attached to that controller. For example, to look at the devices attached to the controller in slot 1, enter: 

        >>> t tc1 cnfg

        A display appears identifying the unit number of each device attached to that controller. Identify the unit number of the device from which you want to boot.

    3. Set the default boot device.

      By default, you must provide a boot device when you boot your system. If you always boot from the same device, use the following command syntax with the bootdef_dev variable to set a default boot device:

      set bootdef_dev device

      For example, to boot the system off of disk dka0, enter: 

      >>> set bootdef_dev dka000

      To boot the system from the first disk on the PMAZB or PMAZC option card in TURBOchannel slot 1, enter the following command. Note that the double quotes ( " ) are necessary for the console to understand where it is booting from. 

      >>> set bootdef_dev "1/dka000"

      Hardware configurations can include HSZ controllers that are connected to dual KZPBA-CB buses and configured for multibus failover. In this case, you specify both bus paths to the boot disk devices when setting the console variable bootdef_dev. During configuration of a dual-controller system, one of the controllers is designated as the preferred path. The boot devices on this controller must be specified as the first arguments to bootdef_dev.

      For example, a system has two controllers A and B connected to four logical volumes dka0, dka1, dkb0, and dkb1. If controller B is designated as the preferred controller, then the console variable bootdef_dev must specify the **b* devices first, as follows:

      For example: 

        >>> set bootdef_dev dkb0.0.0.0.6.0, \
dka0.0.0.5.0

      Separate each device path with a comma; do not use any spaces. If the console is unable to boot from the first device, it will try the next device.

    4. You have the option of booting from an alternate kernel. If you want to do this, enter: 

      >>> set boot_osflags i

      When booting, the system prompts you to enter a file name. For example: 

      Enter [kernel_name] [option_1 ... option_n]: \
genvmunix

      The system will display informational messages.

      On some processors, you can also boot an alternate kernel by setting the boot_file variable to the name of the kernel you want to boot. For example, to boot a genvmunix kernel, enter: 

      >>> set boot_file genvmunix

      Depending on your processor, you may need to clear the boot_file variable if you want to boot the default kernel, /vmunix. For example: 

      >>> set boot_file ""

In a multiprocessor configuration, you can use the set cpu_enable command to selectively enable processors from the console. The mask is a bit field, where each bit represents a slot position. The easiest way to ensure all processors are enabled is to set the CPU mask to ff. After setting the mask, turn the system power switch off and then back on again.

The operating system also provides a mechanism for enabling or disabling processors at system boot time. See the description of the cpu-enable-mask attribute in the System Configuration and Tuning guide for information.

After you have set the console variables, use the following command to boot the system: 

>>> b

2.4.2    Overriding the Boot Commands

The following list describes how to override the commands presented in Section 2.4.1.

2.5    Identifying System Run Levels

A run level (mode) specifies the state of the system and defines which processes are allowed to run at that state. The most commonly used run levels are as follows:

Run Level System State
0 Specifies the halt state
S or s Specifies single-user mode
2 Specifies multiuser mode without network services
3 Specifies multiuser mode with network services
null Specifies the console mode

The inittab file contains line entries that define the specific run levels and the run command scripts that are associated with the run level. When the init process starts, it reads the inittab file and executes the relevant run command scripts. The scripts, in turn, define which processes are to run (and which processes are to be killed if the system is changing from one level to another) at a specific run level. Refer to the init(8) and inittab(4) reference pages and to Chapter 3 for information about reading and modifying the inittab file.

Section 2.6.2 describes how you use the init command to change the run level.

2.6    Changing System Run Levels

Before changing to a new run level, check the inittab file to confirm that the run level to which you intend to change supports the processes you need. Of particular importance is the getty process because it controls the terminal line access for the console and other logins. Make sure that the getty entry in the inittab file allows system console access at all run levels. Refer to the inittab(4) reference page for more information about defining run levels. Refer to the getty(8) reference page for more information about defining terminal lines and access.

Before changing to a new run level, use the wall or write command to warn users that you intend to change the run level. Because a change in run level could result in termination of a user's getty process (which disables their login capability) as well as the termination of other processes that the user is running, you should communicate the change to each logged in user.

Check the getty entry for user terminals to verify that the new run level is specified in the entry. If it is not, request that users log off so that their processes will not terminate in response to a kill signal from init.

When the system is initialized for the first time, it enters the default run level that is defined by the initdefault line entry in the inittab file. The system continues at that run level until init receives a signal to change run levels. The following sections describe these signals and provide instructions for changing run levels.

2.6.1    Changing Run Levels from Single-User Mode

Use the Bourne shell when working in single-user mode and press Ctrl/d to change run levels. The shell terminates in response to Ctrl/d and displays the following message if transitioning from single-user mode to multiuser mode during a boot operation: 

INIT: New run level: 3

If this transition is made from single-user mode with the previous state having been multiuser mode, then a prompt is issued for input of the desired run level. The init process searches the inittab file for entries (at the new run level) with the boot or bootwait keywords, and then acts on these entries before it continues with the normal processing of the inittab file. The init process next scans the file for other entries with processes that are allowed to run at the new run level, and then acts on these entries.

2.6.2    Changing Run Levels from Multiuser Mode

When the system is running at one of the two multiuser run levels, you can use the init command to change run levels. To use the command, log in as root and use the following syntax:

init [ 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | S | s | M | m | Q | q ]

The init command invokes the following run levels:

Run Level System State
0 Specifies the halt state.
2 Specifies a multiuser run level with local processes and daemons.
3 Specifies a multiuser run level with remote processes and daemons.
1,4, and 5through 9 Changes the run level to that specified by the number flag in the /etc/inittab file. If no such entry exists, no action is taken and no message is output.
M, m Moves control to the console device and halts to single-user mode.
Q, q Specifies that init should reexamine the inittab file.
S, s Changes the run level to a single user state with only the essential kernel services.

2.6.2.1    Changing to a Different Multiuser Run Level

To change from the current multiuser run level to a different multiuser run level, enter the init command with the argument that corresponds to the run level that you want to enter. For example, to change from run level 2 to run level 3, enter the following command: 


# init 3

In response to your entry, init reads the inittab file and follows the instructions that correspond to the change in run level.

2.6.2.2    Changing to Single-User Mode

The init command provides a way to change from the current multiuser mode to single-user mode by using the s run level argument. For example, to change from the current run level to single-user mode, enter: 

# init s

To change from a multiuser mode to single-user mode, giving users a 10-minute warning, enter: 


# /usr/sbin/shutdown +10 Bringing system down to single-user for testing

To return to multiuser mode from single-user mode, use Ctrl/d or enter exit at the prompt. This causes the init command as process 1 to prompt you for the run level. In response to the prompt, enter 2 to return to multiuser mode without networking daemons activated, or enter 3 to return to multiuser mode with networking daemons activated.

Alternatively, you can reboot the system by using one of the following commands: 

# /usr/sbin/shutdown -r now



# /sbin/reboot

2.6.2.3    Reexamining the inittab File

To reexamine the inittab file, enter the init command with the q argument, as follows: 

# init q

In response, init reexamines the inittab file and starts new processes, if necessary. For example, if you recently added new terminal lines, init activates the getty process for these terminal lines in response to the init q command.

Refer to the getty(8) reference page for further information about the relationship between terminal lines and the init command.

2.7    Symmetric Multiprocessing

Symmetric MultiProcessing (SMP) consists of two or more processors that execute the same copy of the operating system, address common memory, and can execute instructions simultaneously. In a multiprocessor system, multiple threads can run concurrently through simultaneous execution on multiple processors.

If your system is a multiprocessor system and it is running Tru64 UNIX, it is running in an SMP environment. The objective of the operating system in an SMP environment is to take advantage of the incremental computing power available to the system as additional processors are added. To do this, the operating system must allow multiple threads of execution to operate concurrently across the available processors.

From a system administrator's point of view, this additional computing power requires little to no additional system management work. All the administrator should see is additional available computing power. It may be that additional I/O capabilities will be required to more efficiently utilize the extra power.

2.7.1    Adding CPUs to an Existing System

At boot time, the system determines the number of CPUs available. Adding computing power to your multiprocessing systems is as simple as installing the processor board and rebooting the system. You do not have to reconfigure the kernel; you may have to modify any tuning that was done to limit the number of processors available, and you may need to install a Product Authorization Key (PAK). For more information on PAKs, see the Software License Management manual.

2.7.2    Unattended Reboots on Multiprocessor Systems

If a processor in a multiprocessor system fails, the operating system notes which processor failed, then automatically reboots the system. Although the operating system continues, you must manually restart the failed processor. For instructions, see the Installation Guide.

2.8    Setting and Resetting the System Clock

The system has an internal clock that you set when you install the system. The clock maintains the time and date whether the power is on or off. Nevertheless, there are occasions when you might need to reset the time or date. For example, with battery-powered clocks, you might need to reset the time as a result of battery failure; or you may need to synchronize system time with standard time.

To set the date and time, log in as root and use the following syntax with the date command:

date [[cc]yy]mmddHHMM[.ss]

The sequence of date and time parameters can vary depending on what command options you use. Refer to the date(1) reference page for more information. The following table shows the value of the parameters:

cc Designates the first two numbers of the year (century) as a 2-digit integer.
yy Designates the year as a 2-digit integer
MM Designates the month as a 2-digit integer
dd Designates the day as a 2-digit integer
HH Designates the hour as a 2-digit integer, using a 24-hour clock
mm Designates the minutes as a 2-digit integer
. Serves as a delimiter
ss Designates the seconds as a 2-digit integer (this field is optional)

For example, to set the date to 09:34:00 AM Jan 7, 2000 using the mmddHHMM[[cc]yy][.ss] format, enter one of the following commands: 


# date  010709342000
# date  0107093400.00
# date  010709342000.00

If you are changing the year, the system disk must be updated with the new year information. In single-user mode, enter the mount -u / command after you enter a date containing a new year. This command writes the new year into the superblock on the system disk. Note also that the root file system will now be mounted read-write.

2.9    Troubleshooting Boot Problems

If your system does not boot, the following list suggests some areas for further investigation:

2.10    Shutting Down the System

The following sections describe the shutdown procedures and the recovery strategies that you use in both controlled and unexpected shutdowns. The first part discusses procedures for handling controlled shutdowns. The second part discusses guidelines and recommendations for handling and recovering from unexpected shutdowns.

There are several good reasons to stop the system in a controlled shutdown. For example:

In each of these and similar situations a variety of options are available to you. Regardless of how you decide to resolve the situation, your first step is to initiate a controlled shutdown of the system. There are practical and reasonable ways to shut down your system from single-user mode or multiuser mode.

A system that has panicked or crashed presents you with a different set of circumstances than a system that has shut down in an orderly fashion. This chapter discusses orderly shutdowns only. Refer to Chapter 12 for information on system crashes.

2.11    Stopping Systems While in Multiuser Mode

To shut down the system while running in multiuser mode, use the shutdown command or invoke the SysMan Menu task Shut down the system. When you issue the shutdown command with the -h or -r flags, the program typically performs the following operations in the order shown:

  1. Runs the wall program to notify all users of the impending shutdown

  2. Disables new logins

  3. Stops all accounting and error-logging processes

  4. Runs the killall program to stop all other processes

  5. Runs the sync program to synchronize the disks

  6. Logs the shutdown in the log file

  7. Dismounts file systems.

  8. Halts the system

The following sections describe typical shutdown operations and provide examples of what happens when you use the command flags. Refer to the shutdown(8) reference page for more information.

2.11.1    Using SysMan shutdown

The sysman shutdown command invokes a graphical user interface that you can use to shut down a host system. This interface can also be invoked from the SysMan Station or the SysMan Menu. Refer to Chapter 1 for information on invoking the different SysMan interfaces such as choosing the Shutdown the system option from the General Tasks branch of the SysMan Menu.

Note

The command sysman shutdown replaces the dxshutdown utility, which has been removed to an obsolete utilities subset. If you type dxshutdown at the command line, the new SysMan shutdown interface will be invoked.

When you invoke sysman shutdown, a window titled Shutdown Targeted on host name is displayed, where host name is the local system name. This utility offers additional options if you are shutting down cluster members. Refer to the TruCluster documentation if you are shutting down one or more members of a cluster.

The following options are available:

Once you have initiated a shutdown using the SysMan Menu, the system shuts down as described in Example 2-1 in Section 2.11.2, except that a continuous countdown is displayed in the Shutdown: Countdown window. You can opt to cancel the shutdown at any time.

Refer to the online help for more information on the various options and the shutdown(8) reference page for more information on shutdown behavior.

2.11.2    Shutting Down the System and Warning Other Users

You can perform this task using the shutdown command or by invoking the SysMan Menu task Shut down the system.

To shut down the system from multiuser mode to single-user mode at specific times and warn users of the impending shutdown, follow these steps:

  1. Log in as root and change to the root directory: 

    
# cd /

  2. Use the following syntax with the shutdown command:

    /usr/sbin/shutdown [-bfhknrsc] [-chs] time [ warning-message ]

For example, to shutdown and halt the system in 10 minutes with a warning to users that the system is going down for routine maintenance tasks, enter: 

# /usr/sbin/shutdown +10 "Planned shutdown, log off now"

Example 2-1 shows a typical shutdown sequence.

Example 2-1:  A Typical Shutdown Sequence

# /usr/sbin/shutdown +6 
"Maintenance shutdown, please log off"[1]
System going down in 6 minutes
                       ...Maintenance shutdown, please log off [2]
System going down in 5 minutes
                       ...Maintenance shutdown, please log off [3]
 
No Logins, system going down @ <time>
                       ...Maintenance shutdown, please log off [4]
 
System going down in 60 seconds
                       ...Maintenance shutdown, please log off
System going down in 30 seconds
                       ...Maintenance shutdown, please log off
System going down immediately
                       ...Maintenance shutdown, please log off [5].
.  <process shutdown messages> [6]
.
Halting processes ...
INIT: SINGLE USER MODE [7]
# halt 
.
. <hardware reset messages> [8]
.
resetting all I/O buses
>>> [9]

  1. This command initiates a shutdown, delayed for six minutes, and broadcasts a message to all users warning them to log off. [Return to example]

  2. This message will be immediately echoed to the console terminal, and to the terminal window from which the command was run. [Return to example]

  3. These messages will be immediately echoed to the console terminal, and to the terminal window from which the command was run. The messages are repeated at intervals, depending on the length of the original shutdown delay, becoming more frequent as shutdown time approaches. [Return to example]

  4. When only five minutes remain, any new logins are automatically disabled. If anyone attempts to login at this time, this message will be displayed only at the log in terminal and is not broadcast to other users. [Return to example]

  5. This final message warns that the system will shut down immediately and user processes will be halted. The system stops processes such as accounting and error logging and logs the shutdown in the log file. It then sends the init program a signal that causes the system to transition to single-user mode.

    Note that if you do not specify a shutdown delay (shutdown now) only this message is broadcast before the system begins to shut down and user processes are killed. [Return to example]

  6. As processes are stopped, notification messages are displayed to the console and are logged. [Return to example]

  7. As the system halts, all login terminals (or graphical displays, such as CDE and XDM) are halted, and output is redirected to the console. Various system messages are displayed at the console as processes are shut down and the shutdown ends in single-user (standalone) mode, displaying the console input prompt. Only the root user may now use the system and can perform standalone tasks or use the halt command to completely shut down the system. [Return to example]

  8. Various messages are displayed as system components are initialized. [Return to example]

  9. The console prompt (>>>) is displayed. You can now turn off power to the system, reboot the system, or enter console commands. [Return to example]

2.11.3    Shutting Down and Halting the System

Use this procedure to shut down the system from multiuser mode, warn all users, and halt all systems. You can also invoke the SysMan Menu task Shut down the system to perform the same operation.

  1. Log in as root and change to the root directory: 

    
# cd /

  2. Use the following syntax with the shutdown command:

    shutdown -h time [ warning-message ]

For example, to shut down and halt the system in 5 minutes with a warning to users that the system is going down for maintenance, enter: 

# shutdown -h +5 /
Maintenance shutdown in five minutes

The system begins to shut down as described in Example 2-1. However, the system also halts automatically and does not stop at the standalone (single-user) prompt. Instead, the console prompt is displayed and you can turn off power to the system, reboot, or use the console commands as described in the Owners manual for your system.

2.11.4    Shutting Down and Automatically Rebooting the System

Use this procedure to shut down the system from multiuser mode, warn all users, and automatically reboot the system to multiuser mode. You can also invoke the SysMan Menu task Shut down the system to perform this operation.

  1. Log in as root and change to the root directory: 

    
# cd /

  2. Use the following syntax with the shutdown command:

    shutdown -r time [ warning-message ]

For example, to shut down and automatically reboot the system in 15 minutes with a warning to users that the system is going down for a reboot, enter the following command: 

# shutdown -r +15 \
Shutdown and reboot in 15 minutes

The system begins to shut down as described in Example 2-1, notifying users of the impending shutdown, disabling logins, and then proceeds with the standard shutdown activities. When it completes these activities, shutdown automatically starts the reboot operation, which involves running fsck for a consistency check on all mounted file systems. If problems are not encountered, the system reboots to multiuser mode.

Note

If fsck finds file system inconsistencies, it displays a warning message, recommending that you run fsck again from single-user mode before operating the system in multiuser mode.

2.11.5    Shutting Down and Halting Systems Immediately

Use the following procedure to shut down and halt the system immediately. You can also invoke the SysMan Menu task Shut down the system to complete this operation:

  1. Log in as root and change to the root directory. For example, enter the following command: 

    # cd /

  2. Enter the shutdown command as follows: 

    # shutdown -h now

The system begins to shut down as described in Example 2-1 except that the shutdown is immediate and without prior warning to users. When all processes are shut down, the system is halted and the console prompt (>>>) is displayed. You can turn off power to the system, reboot it, or use the console commands as described in the Owners Manual for your system.

Note

Use this form of the command if no other users are logged into the system or if you need to shut down in an emergency. User processes will be stopped without warning and user data may be lost.

2.12    Stopping Systems While in Single-User Mode

Although the shutdown command is your best choice for shutting down systems, there are other commands available (but not recommended) for stopping systems, namely: halt, fasthalt, fastboot, and reboot. These commands should be invoked only from single-user mode.

If you are working in single-user mode, you can stop systems by entering the following commands: 

# /sbin/sync
# /sbin/sync
# /usr/sbin/halt

In response to the halt command, the program logs the shutdown in the log file, kills all running processes, executes the sync system call and waits for all information to be written to disk, then halts the systems. Note that entering the sync command at least twice ensures that all data in memory is safely written to disk. Refer to the halt(8) reference page for a description of the command and its flags.

Refer to the fasthalt(8), fastboot(8), and reboot(8) reference pages for more information on the other options.

2.12.1    Stopping and Rebooting Systems with the reboot Command

If you are working in single-user mode, you can safely shut down and automatically reboot your system to multiuser mode with the reboot command, which has the following syntax:

reboot [ [-dlnq] ]

Use this command to reboot the system as follows: 


# /usr/sbin/reboot
 
 

When you run the reboot command without options, it stops all processes, synchronizes (sync) the disks, then initiates and logs the reboot. However, if you need to shut down and reboot the system abruptly, enter the following command: 


# reboot -q

In response to this command, the system shuts down abruptly without stopping processes and performing other shutdown activities. The command initiates a reboot without logging the event. Refer to the reboot(8) reference page for a description of the command and its flags.

2.12.2    Stopping Systems with the fasthalt Command

If you are working single-user mode, you can halt a system immediately using the fasthalt command, which has the following syntax:

fasthalt [-lqn]

Use this command to halt the system as follows: 


# /usr/sbin/fasthalt
 
 

When you invoke fasthalt without options, it halts the system and flags a subsequent reboot to skip the execution of fsck. The program creates the fastboot file, then invokes the halt program. The system startup script contains instructions to look for the fastboot file. If present, the script removes the file and skips the invocation of the fsck command. If you invoke the command without the -l, -n, or -q flag, the halt program logs the shutdown using the syslogd command and places a record of the shutdown in the login accounting file, /var/adm/wtmp.

For a description of the fasthalt command, see the fasthalt(8) reference page.

2.12.3    Stopping Systems with the fastboot Command

If you are working in single-user mode, and do not need to check file systems, you can halt and reboot the systems with the fastboot command, which has the following syntax:

fastboot [-l -n -q]

Use this command to halt and reboot the system as follows: 

# /usr/sbin/fastboot
 
 

When you invoke fastboot without options, it creates a file named /fastboot, halts the system, then immediately reboots the system without checking file systems with fsck.

For a description of the fastboot command, see the fastboot(8) reference page.