2    Starting Up and Shutting Down the System

This chapter describes procedures for starting up and shutting down the operating system and includes a discussion of:

• Boot operation

• Different startup states and the corresponding boot preparation

• Run levels

• Resolving problems that occur during the boot operation

Refer to the Installation Guide for information about installing the system and performing the initial boot operation. The information in this chapter assumes that you are booting or rebooting an installed operating system.

Shutting down the system is a routine task that you should perform periodically. 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.

2.1    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 since 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, and be prepared to respond if problems occur.

Although certain boot operations are hardware dependent, some features typically apply to all systems. For example:

• 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:

  • If the boot operation succeeds, the system is initialized. In single-user mode, the system displays the root prompt (#) on the console or on the terminal screen. In multiuser mode, the system displays the login prompt or a startup display. The prompt or startup display differs according to hardware capability and available startup software.

  • If the boot operation fails, the system displays an error message followed by a console firmware prompt (>>>). In the worst case, the system hangs without displaying a console prompt.

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

  • In a boot to single-user mode, the software loads the kernel and proceeds through the initialization tasks associated with process 0 (initialization) and process 1 (init). The init program creates a Bourne shell (sh), turns control over to you, and waits for you to exit from the shell with the exit command or Ctrl/d before continuing with its startup tasks.

    Because init 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 Digital 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.2    Preparing to Boot the Installed System

As the system administrator, you set up or encounter various preboot or postshutdown states. This section describes and recommends procedures for preparing and initiating a reboot from a variety of system states. The states discussed here include the following:

• A powered-down system

• A powered-up, halted system

• A powered-up system in single-user mode

• A crashed system

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.2.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 upon powerup, 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.3 for more information on setting the default boot action for your system.

5. Decide which startup mode you want to initiate:

   • If you have tasks you need to accomplish and want the system to restrict access to all users but root, plan to boot to single-user mode.

   • If you do not require single-user access and you want the system to initialize full functionality, plan to boot to one of the multiuser modes: multiuser without networking or multiuser with networking.

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

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

2.2.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:

   • If you have tasks you need to accomplish and you want the system to restrict access to all users but root, plan to boot to single-user mode.

   • If you do not require single-user access and you want the system to initialize full functionality, plan to boot to one of the multiuser modes: multiuser without networking or multiuser with networking.

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

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

2.2.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:

   • If you have additional tasks that you need to perform and you want the system to deny access to all users but root, plan to continue in single-user mode.

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

2. When you are ready to go to multiuser mode, press Ctrl/d.

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

2.2.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. Confirm that the hardware and all peripheral devices are connected.

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

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

   • In the unlikely event that the diagnostic test indicates hardware failure, contact your Digital field representative. Because hardware damage is a serious problem, do not continue or try to bypass the defective hardware.

   • If you have enabled your system to boot automatically, 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.

4. Decide which startup mode you want to initiate:

   • If you need to deny access to all users but root, plan to work in single-user mode. After a crash, it is wise to work initially in single-user mode. You should check all file systems thoroughly for inconsistencies and perform other postcrash operations before enabling system access to other users.

   • If you need to allow access to you and to all other users with login permission, plan to boot to one of the multiuser modes: multiuser without networking or multiuser with networking.

5. Enter the required boot command.

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

2.3    Booting the System

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

• Processor type

• Run level

• Location of the kernel that you are booting (on the system disk or on a remote server)

• Whether you are booting all processors or a single processor (in a multiprocessor system)

• Whether any console environment variables are defined

• Whether you are booting the default kernel or an alternate kernel

2.3.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. If you are booting a DEC 2000 processor, refer to the hardware manual that accompanied the processor for information on boot commands.

Table 2-1: Console Environment Variables

To prepare the hardware:

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. For DEC 3000 and DEC 7000 processors, set the boot_reset variable to on to force the resetting of the hardware before booting:

   >>>  set boot_reset on
   

3. For DEC 3000 processors, 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. (By default, kdebug is not used.)
      d	Use full crash dumps. (By default, partial dumps are used.)
      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
         

         The previous 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"
      

   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 DEC 4000 and DEC 7000 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
      

      On DEC 4000 and DEC 7000 processors, you must 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 power on the system 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 Tuning and Performance Management guide for information.

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

>>>  b

2.3.2    Overriding the Boot Commands

The previous section described how to set the boot commands. This section describes how to override those commands.

• Overriding bootdef_dev

  To override the bootdef_dev variable, supply the desired boot device as an argument to the boot command. For example, if your boot device is set to boot from disk dka0 and you want to boot from disk dkb0, enter:

  >>>  b dkb0
  

• Overriding boot_osflags

  The boot_osflags variables are ignored if you specify the -fl option to the boot command, as follows:

  >>>  b -fl
  

  To override the boot_osflags variables, pass the desired choices to the -fl option. For example, the following command boots to the interactive prompt so you can specify an alternate kernel, and then boots to multiuser mode:

  >>>  b -fl ai
  

• Overriding boot_file

  To boot a kernel other than that specified by boot_file, enter the boot command with the following syntax:

  b -fi "kernel"

  
  For example, to boot the genvmunix kernel, enter:

  >>>  b -fi genvmunix
  

2.4    Identifying the System Run Levels

A run level (mode) specifies the state of the system and defines which processes are allowed to run at that state. There are four basic run levels available, as follows:

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

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.

2.5    Changing the 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 since it controls the terminal line access for the system 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. Since a change in run level could result in termination of the user's getty process (which disables their login capability) as well as termination of other processes that they are 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.5.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.5.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 | s | 2 | 3 | q ]

The init command invokes the following run levels:

0	Specifies the halt state
s	Specifies the single-user run level
2	Specifies a multiuser run level with local processes and daemons
3	Specifies a multiuser run level with remote processes and daemons
q	Specifies that init should reexamine the inittab file

2.5.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.5.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.5.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.6    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 Digital 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 computes 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 computes. It may be that additional I/O capabilities will be required to more efficiently utilize these extra computes.

2.6.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.6.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.7    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 yyMMddhhmm.ss

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 and time to 1:02:47 p.m. on Jan 19, 1994, you would enter the following command:

#  date 9401191302.47

Note

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.

Refer to the date(1) reference page for more information.

2.8    Resolving Booting Problems

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

• Hardware failure

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

• Software failure

  Software can fail for the following reasons:

  • An incorrect boot path was specified

    Refer to Section 2.3 or your system's hardware guide for instructions on specifying the correct boot path.

  • The kernel is corrupt

    If you suspect that the kernel may be corrupt, try booting the generic kernel, /genvmunix. This will provide you with a fully functional system and you can begin debugging procedures using the kdbx or dbx utilities to analyze crash dumps. Refer to the kdbx(8) or dbx(1) reference pages for more information. Refer to Section 2.3.1 for information on booting an alternate kernel.

  • A disk or file system is corrupt

    If a disk or file system is corrupt, run the fsck command on the file system. The fsck command checks and repairs UNIX File Systems (UFS). If fsck finds something wrong, it prompts you for an action to take. Use extreme care under these circumstances so that you do not inadvertently overwrite or remove any files. Refer to the fsck(8) reference page for more information. If you have an Advanced File System (AdvFS), disk corruption is very unlikely.

    AdvFS provides disk recovery during the mount procedure that corrects the disk structures. You do not need to run the fsck command or any other command. Consequently, recovery of AdvFS is very rapid.

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

Note

You can also use the SysMan dxshutdown command for some of these tasks.

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

• You need to upgrade your software or add new hardware to your configuration. You shut down the system to set up the new additions, make the necessary adjustments to your configuration files, and build a new kernel.

• You have been monitoring the hardware error log and have noticed repeated warnings. You suspect that your hardware may soon fail so you shut down the system and examine the problem.

• You notice that system performance is degrading rapidly. You check the system statistics and conclude that some changes to the system would improve performance. You shut down and tune the system.

• You notice signs of possible file system corruption. You shut down the system and run the fsck program to fix problems or to confirm that none exist.

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. However, this chapter discusses orderly shutdowns only.

2.10    Stopping Systems While in Multiuser Mode

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

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 disk(s)

6. Logs the shutdown in the log file

7. Unmounts 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.10.1    Shutting Down the System and Warning Other Users

To shut down the system from multiuser mode to single-user mode at a specific time and warn users of the shutdown:

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

   #  cd /
   

2. Use the following syntax with the shutdown command:

   shutdown time [ warning-message ]

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

#  shutdown +10 Maintenance shutdown

The system begins to notify users of the impending shutdown. Next, it disables logins, stops accounting and error logging, stops all remaining processes, logs the shutdown in the log file, and sends the init program a signal that causes the system to transition to single-user mode.

When the system's shutdown completion message appears, the shutdown is complete. You can access the system through the console to perform the desired administrative tasks. When you are finished, reboot the system.

2.10.2    Shutting Down and Halting the System

To shut down the system from multiuser mode, warn all users, and halt all systems:

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 shutdown program begins to notify users of the impending shutdown, disables logins, and proceeds with the standard shutdown activities. At the specified shutdown time, the systems are halted.

2.10.3    Shutting Down and Automatically Rebooting the System

To shut down the system from multiuser mode, warn all users, and automatically reboot the system to multiuser mode:

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

In this case, the system begins to notify users of the impending shutdown, disables logins, and 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.10.4    Shutting Down and Halting Systems Immediately

To shut down and halt the system immediately:

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
   

In response to this command, the system shuts down immediately and halts the system.

Note

Do not use this command when there are other users on the system. Users get no warning messages and their processes are immediately stopped.

2.11    Stopping Systems While in Single-User Mode

Although the shutdown command is your best choice for shutting down systems, you can also use the halt command. This command 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:

#  sync
#  sync
#  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.