2    Starting Up and Shutting Down the System

This chapter contains the following information:

2.1    Overview of the Shutdown and Boot Operations

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.

Tru64 UNIX enables you to minimize the number of shutdowns and, thus, maximize the time your system is running with these features:

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:

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.

Automatic Shutdown

Configure system-monitoring tools such as environmental monitoring to shut down the system automatically if certain system events occur. See Chapter 13 for information on event management.

Manual Shutdown

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

Additional documentation relevant to system shutdowns and reboots can be found in manuals, reference pages, and online help.

2.1.3.1    Manuals

The following list refers to information on using system shutdowns and reboots in the Tru64 UNIX operating system documentation set.

This manual also contains the following topics of relevance to planning and managing shutdowns and error recovery:

2.1.3.2    Reference Pages

The following reference pages provide more information on the command options and interfaces:

shutdown(8)

Invocation and use of the shutdown command line interface.

sysman(8) and sysman_station(8)

Information on the use of the SysMan options and a description on invoking these utilities so that you can then run the "Shutdown the System" task.

wall(1) and rwall(1)

Utilities to write to users (warning them of a system shutdown).

halt(8) and fasthalt(8)

Utilities to halt the system.

reboot(8) and fastboot(8)

Utilities to boot the system.

fsck(8)

Utility to examine and repair the UFS file system.

init(8)

Utility for initializing the system.

rc0(8), rc2(8), and rc3(8)

Command scripts that are run when stopping the system, entering run level 2, and entering run level3.

consvar(8)

Command to manipulate system firmware console environment variables.

2.1.3.3    Online Help

The following online help is available:

See Chapter 1 for information on invoking online help.

2.1.4    System Files

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

/etc/inittab

Provides the init program with instructions for creating and running initialization processes.

/vmunix

The default name of the custom kernel. When you build a custom kernel, you can choose any legal file name.

/genvmunix

The default name of the generic kernel. You boot the generic kernel to build a custom kernel, or if the custom kernel is corrupt and non-bootable.

/sbin/rc0, /sbin/rc2, and /sbin/rc3

Run level command scripts.

The rc0 script contains run commands that enable a smooth shutdown and bring the system to a single-user state. The run commands are contained in the /sbin/rc0.d directory.

The rc2 script contains run commands that enable initialization of the system to a multiuser state; run level 2. The run commands are contained in the /sbin/rc2.d directory.

The rc3 script contains run commands that enable initialization of the system to a multiuser state; run level 3. The run commands are contained in the /sbin/rc3.d directory.

2.1.5    Related Utilities

You also may use the following utilities during the boot operation:

fsck

The fsck command is a wrapper program for the ufs_fsck program, which examines and repairs UFS file systems. See advfs(4) and the AdvFS Administration manual for information on verifying AdvFS file systems

consvar

The consvar command gets, sets, lists, and saves console environment variables while the operating system is still running.

To see if your system supports consvar, use the following command: 

# /sbin/consvar -l
auto_action = HALT
boot_dev = dsk0
bootdef_dev = dsk0
booted_dev = dsk0
boot_file = 
booted_file = 
boot_osflags = A
.
.
.

If consvar is supported, the current settings of several console variables are displayed.

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 verification 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 may verify new hardware, mount and verify 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 verifying 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. Also, you can 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 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. See the operator's manual for your hardware for information and instructions for interpreting diagnostic output.

  2. Power up peripheral devices. See the operator's manual or the hardware user's manual for instructions on starting them.

  3. Power up the processor.

  4. Confirm that the hardware completed its restart and diagnostic operations. Most hardware provides a diagnostic examination as a routine part of its startup operation. See 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. See the hardware operator's manual 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:

    single-user mode

    Plan to use this mode if you have tasks you need to accomplish and want the system to restrict access to all users but root.

    multiuser modes

    Plan to boot to one of the multiuser modes (multiuser without networking or multiuser with networking) if you do not require single-user access and you want the system to initialize all functions.

  7. Enter the boot command that corresponds to the startup mode you want. See 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:

    single-user mode

    Plan to use this mode if you have tasks you need to accomplish and want the system to restrict access to all users but root.

    multiuser modes

    Plan to boot to one of the multiuser modes (multiuser without networking or multiuser with networking) if you do not require single-user access and you want the system to initialize full functionality.

  2. Enter the boot command that corresponds to the startup mode you want. See Section 2.4 for the commands and procedures required to boot your system.

2.3.3    Preparing to Transition from Single-User Mode

The system is in single-user mode when it is powered up and enabled, the processor is running, and access is limited to root.

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:

    single-user mode

    Continue in this mode if you have additional tasks to perform and you want the system to restrict access to all users but root.

    multiuser modes

    Plan to go on to one of the multiuser modes (multiuser without networking or multiuser with networking) if you do not require single-user access, or if you have completed your tasks and you want the system to initialize full functionality.

  2. When you are ready to go to multiuser mode, press Ctrl/d. See 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. See Chapter 12 for information on saving crash dump files, and to verify 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. See the operator's manual for your hardware for information and instructions for interpreting diagnostic output:

  5. Decide which startup mode you want to initiate:

    single-user mode

    Plan to work in this mode if you need to deny access to all users but root. After a crash, it is wise to work initially in single-user mode. Verify all file systems thoroughly for inconsistencies and perform other post crash operations before enabling system access to other users.

    multiuser modes

    Plan to boot to one of the multiuser modes (multiuser without networking or multiuser with networking) if you need to allow access to you and to all other users with login permission

  6. Enter the required boot command. See 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. You may want to remove a functioning system from a network to use the system in standalone mode or to correct a system problem, such as a failed network device.

If you take a system out of a network without reconfiguring the services, or if a system crashes and you must disconnect it from the network, perform the additional steps before rebooting the system

There may be instances 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

    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 writable by using the following command: 

    # mount -u /

    Mounting the root file system as writable 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. Do not modify these files with anything other than the rcmgr command. If the format of the files is not correct, other subsystems or utilities may not parse the files correctly. See rcmgr(8) for more information. See 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), 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

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

Examples of typical console settings are shown in this section. See the hardware documentation that came with your system for specific information. See also the information on booting systems in the Installation Guide and the Installation Guide — Advanced Topics manual.

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. See your storage array documentation.

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.

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. See the Kernel Debugging manual for more information.
      d Use full crash dumps. (By default, partial dumps are used.) See Chapter 12 for information on crash dumps.
      i Prompt for the kernel and special arguments. (By default, no prompts are displayed). See Section 2.4.3 for an example of an interactive boot.

      The options are concatenated into the boot_osflags variable to achieve the effect you want. 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 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, 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 manual for more 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 enter other boot options and parameters with the -i option. (See the owner's manual 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'#
#

    The following options are now available:

    1. Enter the name of an alternate kernel and specify required boot options. See 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 file names, 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. See init(8), inittab(4), and 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, see 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 may 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.

Examine 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 and 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 theinittab 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 more 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 may need to modify any tuning that limits the number of processors available. See the System Configuration and Tuning manual for more information. If you need to install a Product Authorization Key (PAK) 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 records which processor failed, then automatically reboots the system. Although the operating system continues, you must restart the failed processor manually. 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 may need to reset the time or date. For example, with battery-powered clocks, you may 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 date command. The sequence of date and time parameters can vary depending on what command options you use. (See date(1) for more information.) Table 2-3 shows the value of the parameters:

Table 2-3:  Parameters of the date command

Parameter Description
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. Sep 7, 2002 using the mmddHHMM[[cc]yy][.ss] format, enter one of the following commands: 

# date  090709342002
# date  0907093402.00
# date  090709342002.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 suggests some areas for further investigation.

2.9.1    Hardware Failure

See the hardware manual accompanying your system for hardware test procedures. If a hardware problem exists, follow the instructions in the manual for resolving the problem.

2.9.2    Software Failure

Software can fail for the following reasons:

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. See 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 invoke this interface from the SysMan Station or the SysMan Menu. See 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 shutdown 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:

Shutdown type

Use this option menu to select one of the following shutdown options:

Halt

Halt the operating system and display the console prompt

Reboot

Shut down and halt the system, then automatically reboot it

Single user

Shut down to single-user mode, displaying the superuser prompt (#)

Message only

Broadcast a message to all current system users without shutting down the system

Minutes until shutdown

Hold down mouse button 1 (MB1) and move the slider bar to select the elapsed time in minutes before the shutdown operation begins (the shutdown delay). The time is displayed adjacent to the bar. You can select from a range of 0-60 minutes by using the slider bar. In some user environments, such as on a character-cell terminal, the slider bar is not available and you type a number to specify the shutdown delay. In these interfaces you can specify a time greater than 60 minutes.

Shutdown message

Type a message to users warning of the impending shutdown and requesting that they log out. This message, if any, is in addition to the message that is sent by default.

In a shutdown that is not now, messages are issued when the shutdown is started, and at regular intervals thereafter. For example, if a shutdown is requested in 55 minutes, messages are issued at 55, 50, 40, 30, 20, 10, 5, and 1 minute before shutdown, at 30 seconds before shutdown, and at shutdown time.

Broadcast message to NFS clients

Check this box if you want to broadcast a message to remote users of local NFS-served file systems. If a remote user is connected to any file system that is exported by the local system, that user receives a warning of the impending shutdown. To send such messages, ensure that the rwalld daemon is running on the remote user's system.

Execute run-level transition scripts

Check this box if you want to run the existing run-level transition scripts in the /sbin/rc[N.d]/[Knn_name] file. For example, /sbin/rc0.d/K45.syslog. See the -s option in shutdown(8) for more information.

Preshutdown Script

Specify a path to a custom script that you want to run before the shutdown completes. The script is run at shutdown time and completes any tasks that you specify prior to shutting down the system. If your script (or any intermediate scripts that it calls) fails to complete successfully, the system may not shut down correctly.

Other options

Check this box to enable options that make the shutdown faster:

Fast

Performs a fast shutdown, bypassing messages to users and NFS clients

No disk sync

Shuts down without synchronizing the disks by using the sync operation.

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.

See 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 echoed to the console terminal immediately, and to the terminal window from which you invoked the shutdown command. [Return to example]

  3. These messages are echoed to the console terminal, and to the terminal window from which you invoked the shutdown command immediately. 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 disabled automatically. If anyone attempts to log in at this time, this message is displayed at the login 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 (#). Now only the root user can use the system and perform standalone tasks or use the halt command to shut down the system completely. [Return to example]

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

  9. The console prompt (>>>) is displayed. Now you can 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 also can 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 also can 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 command 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. Also, you can 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 may 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 written safely to disk. See halt(8) for a description of the command and its flags.

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

See fasthalt(8) for more information.

2.12.3    Stopping Systems with the fastboot Command

If you are working in single-user mode and do not need to verify 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 verifying file systems by using the fsck command. See fastboot(8) for more information.