2    Starting Up and Shutting Down the System

Shutting down the system and then restarting it are routine tasks that you need to perform periodically. In some computing environments, 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. Develop a site-specific operations manual to define your:

This chapter contains the following information:

2.1    Overview of the Shutdown and Boot Operations

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

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

The Shutdown icon in the CDE Application Manager - DailyAdmin folder invokes the SysMan Menu task named "Shutdown the System".

2.1.2    Boot Methods

You boot the operating system by using the system's console. 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, the 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

You might also use the following utilities 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 must understand what is happening during the system boot operations, and be prepared to respond if problems occur.

2.2.1    Booting Automatically or Manually

The system boots either automatically or manually. In an automatic boot, the system begins the initialization process and continues until completion or failure. You need only to intervene manually if the automatic boot fails for some reason. For example, if the fsck command cannot verify file systems.

In a manual boot, the system controls the initial operation, turns control of the procedure over to you and 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 the init operation 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 and module loading.

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 operating system allows you to boot an alternate kernel if your custom kernel is not bootable. You can boot the generic kernel (/genvmunix) to troubleshoot the problem with your system. You can also boot an alternate custom 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 superuser prompt, enter the following command: 

# mount -u /

2.3.1    Preparing to Boot a Powered-Down System

Follow these steps to power-up and boot your system:

  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 peripheral devices. Refer to the operator's manual or the hardware user's guide for instructions on starting your peripheral devices.

  3. Power up the processor.

  4. 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.

  5. Wait for the console prompt (>>>). If you 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.

  6. Decide which startup mode you want to initiate:

  7. 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 superuser prompt ( # ), follow these steps to prepare to go to multiuser mode:

  1. Decide if you need to continue in single-user mode or if you require 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 tries to start all the network services that are configured. This results 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 you must disconnect it from the network, perform the additional steps before rebooting the system.

You might also 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

    If you intend to do things such as boot from an alternate disk, set the appropriate console variables at this time. See Section 2.4.1 for more information.

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

    >>> boot

  3. When the system displays the superuser (#) prompt, mount the root file system as writeable by using the following command: 

    # mount -u /

    Mounting the root file system as writeable enables you to use the ed line editor to edit system files and to access 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 is important for startup operations and for system configuration. Avoid modifying these files with anything other than the rcmgr command. If the format of the files is not correct, other subsystems or utilities might not parse the files correctly. See rcmgr(8) 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 complete the modifications, halt the system and reset any console environment variables. For example: 

    >>> set boot_osflags a
>>> boot

  7. Your system reboots to multiuser mode, without attempting to start any network services.

There are variations in the console commands depending on your system model and the firmware revision. 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.

This section provides examples of typical console settings. Refer to your hardware documentation that came with your system for specific information. See also the information on booting systems in the Installation Guide and Installation Guide -- Advanced Topics.

If you are using RAID storage arrays or fibre channel controllers in a storage area network you must use the appropriate storage management software to get and set boot device information. Refer to your storage array documentation.

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
cpu_enable Selectively enables particular processors from the console

To prepare the hardware for the boot operation, perform the following operations at the console prompt:

  1. Set the auto_action variable to halt: 

    >>> set auto_action halt

    This command halts 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

      Option 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 prompts are displayed). Refer to Section 2.4.3 for an example of an interactive boot.

      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

    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 with the bootdef_dev variable to set a default boot device. For example, to boot the system off of disk dka0, enter: 

      >>> set bootdef_dev 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 bootdef_dev console variable. During configuration of a dual-controller system, one of the controllers is designated as the preferred path. Specify the boot devices on this controller as the first arguments to the bootdef_dev console variable.

      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 bootdef_dev console variable  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 spaces or tab characters. If the console is unable to boot from the first device, it tries 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 path to the kernel. For example: 

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

      The system displays informational messages.

      On some processors, you can 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 generic kernel (/genvmunix), enter: 

      >>> set boot_file genvmunix

      Depending on your processor, you might 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, cycle the system power.

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.4.3    Using Interactive Boot to Verify the Root File System

Use the -flags i option with the console boot command to invoke an interactive boot session. Depending on the console command options available for your system, you can choose to enter other boot options and parameters with the -i option. (Refer to the owner's guide for your processor for more information on interactive boot options.)

The interactive boot session runs the osf_boot command that is located in the root file system (/). It enables you to examine the root file system without fully booting the system. Use the following procedure to perform this task. It is assumed that your system is shut down and at the console prompt:

  1. From the console prompt (>>>) enter the following command to boot the system in interactive mode: 

    >>> boot -flags i
 
 

  2. The following message is displayed: 

    UNIX Boot - date
 
Enter: <kernel_name> [option_1...option_n]
or: ls [name]['help'] or quit to return to console
Press return to boot 'vmunix'#
#

    You options at this point are as follows:

    1. Enter the name of an alternate kernel and specify required boot options. Refer to the owner's manual for your system for a list of boot options.

    2. Enter the following command to obtain help on the ls command: 

      # help

      The ls command options are described in Step 3 below.

    3. Enter the quit command to return to the console prompt.

    4. Press Return to boot the default custom kernel (/vmunix) if no other kernel is specified by the boot_file console variable.

  3. Use the ls command to list the content of root file system directories or to list specific files. If you do not specify a file name, the entire content of the directory is displayed. The following are examples of valid commands:

    Wildcard characters are supported for filenames, but not directory names.

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 run (and which processes are killed if the system changes from one level to another) at a specific run level. Refer to init(8), inittab(4), 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. See inittab(4) for more information about defining run levels. See getty(8) for more information about defining terminal lines and access.

A change in run level can terminate a user's getty process, disabling their login capability and might terminate other user processes. Before changing to a new run level, use the wall or write command to warn users that you intend to change the run level.

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 are not terminated in response to a kill signal from the init process.

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 the init process 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 in Single-User Mode

Use the Bourne shell when working in single-user mode and press Ctrl/d to change run levels. When you press Ctrl/d, the shell terminates the following message is displayed: 

INIT: New run level: 3

You typically see this message when you transition from single-user mode to multiuser mode during a boot operation. At other times, you are prompted to supply a run level. See init(8) for more information about run level transitions.

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 as follows:

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,5 - 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 displayed.
M, m Moves control to the console device and halts to single-user mode.
Q, q Specifies that the init process 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, the init process 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, type Ctrl/d or enter the exit command 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, the init process reexamines the inittab file and starts new processes, if necessary. For example, if you recently added new terminal lines, the init process activates the getty process for these terminal lines in response to the init q command.

See getty(8) 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.

2.7.1    Adding CPUs to an Existing System

At boot time, the system determines the number of CPUs available. To add computing power to your multiprocessing system, install the processor board and reboot the system. You do not have to reconfigure the kernel but you might need to modify any tuning that limits the number of processors available. See System Configuration and Tuning for more information. If you need to install a Product Authorization Key (PAK) see Software License Management.

2.7.2    Unattended Reboots on Multiprocessor Systems

If a processor in a multiprocessor system fails, the operating system records 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 might need to synchronize system time with standard time.

To set the date and time, log in as root and use the date command. The sequence of date and time parameters can vary depending on what command options you use. (See date(1) 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 a.m. 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 change the year, update the system disk 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. The root file system is 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 for both controlled and unexpected shutdowns. The first part discusses procedures for controlled shutdowns. The second part discusses guidelines and recommendations for recovering from unexpected shutdowns.

Typical reasons for shutting down a system are:

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. See shutdown(8) for more information.

2.11.1    Using SysMan shutdown

Use the sysman shutdown command to invoke the SysMan Menu shut down task. You can also invoke this interface 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.

When you enter sysman shutdown, a window titled "Shutdown Targeted on host name" is displayed, where host name is the local system name. The shut down task provides you with additional options if you are shutting down cluster members. See the TruCluster documentation if you are shutting down one or more members of a cluster.

The following options are available:

After you initiate a shutdown by 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 cancel the shutdown at any time.

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

2.11.2    Shutting Down the System and Warning Other Users

You can perform this task by 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 shutdown command to initiate a shutdown. For example, to shut down and halt the system in 10 minutes with a warning to users that the system is shutting 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 is immediately echoed to the console terminal, and to the terminal window from which you invoked the shutdown command. [Return to example]

  3. These messages are immediately echoed to the console terminal, and to the terminal window from which you invoked the shutdown command. 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 five minutes remain, new logins are automatically disabled. If anyone attempts to login at this time, this message is displayed at the log in terminal and it is not broadcast to other users. [Return to example]

  5. This final message warns that the system is shutting down immediately and user processes are 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.

    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 mode, displaying the superuser prompt (#). Only the root user can 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 shutdown command to shut down and halt the system. 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 superuser 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 owner's 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 shutdown to initiate a shut down followed by an automatic reboot. 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, the shutdown procedure automatically starts the reboot operation, which involves running the fsck command for a consistency check of all mounted file systems. If problems are not encountered, the system reboots to multiuser mode.

Note

If the fsck command finds file system inconsistencies, it displays a warning message recommending that you run the fsck command 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 perform 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 owner's manual for your system.

Note

Use this form of the shutdown command if no other users are logged in to the system or if you need to shut down in an emergency. User processes are stopped without warning and you might lose user data.

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. Invoke these commands 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

The following events occur in response to the halt command:

Entering the sync command at least twice ensures that all data in memory is safely written to disk. See halt(8) for a description of the command and its flags.

Refer to fasthalt(8), fastboot(8), and reboot(8) 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, as follows: 

# /usr/sbin/reboot
 
 

When you run the reboot command without options, it stops all processes, synchronizes 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. See reboot(8) for a description of the command and its flags.

2.12.2    Stopping Systems with the fasthalt Command

If you are working in single-user mode, you can halt a system immediately by using the fasthalt command as follows: 

# /usr/sbin/fasthalt -n
 
 

When you invoke the fasthalt command without options, it halts the system and flags the subsequent reboot to prevent the execution of the fsck command . 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 by 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 fasthalt(8).

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, as follows: 

# /usr/sbin/fastboot
 
 

When you invoke the fastboot command without options, it creates a file named /fastboot, halts the system, then immediately reboots the system without checking file systems by using the fsck command. For a description of the fastboot command, see fastboot(8).