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.
Although certain boot operations are hardware dependent, some features
typically apply to all systems. For example:
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:
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.
If you are preparing to reboot your system from a powered-down state,
follow these steps:
Refer to Section 3.3 for the commands and procedures
required to boot your system.
When the system displays the console prompt, follow these steps to prepare
to boot your system:
Refer to Section 3.3 for the commands and procedures
required to boot your system.
When the system displays the single-user prompt (#), follow these steps to prepare to go to multiuser mode:
Refer to Section 3.3 for the commands and procedures
required to boot your system.
3.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.
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.
3.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:
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 /
3.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.
3.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 (>>>).
3.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.
3.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:
3.3 Booting the System
The command that you use to boot the kernel depends on several factors:
3.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 3-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.
>>> set auto_action haltThe 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.
>>> set boot_reset on
>>> set scsi_reset 4
>>> set boot_osflags adIf you want the defaults, clear the variable as shown in the following example:
>>> set boot_osflags ""
>>> show deviceIf you want to boot from the dual SCSI TURBOchannel option card (PMAZB or PMAZC), complete the following steps:
>>> show confThe previous command displays the system configuration.
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 cnfgA 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.
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 dka000To 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"
>>> set boot_osflags iWhen booting, the system prompts you to enter a file name. For example:
Enter [kernel_name] [option_1 ... option_n]: genvmunixThe 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 genvmunixOn 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 ""
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
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:
The boot_osflags variables are ignored if you specify
the -fl option to the boot command, as follows:
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:
3.3.2 Overriding the Boot Commands
The previous section described how to set the boot
commands. This section describes how to override those commands.
>>> b dkb0
>>> 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
>>> b -fi genvmunix
| 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 |
| Specifies the console mode |
init(8)
and inittab(4) reference pages and to Chapter 4
for information about reading and modifying the inittab
file.
3.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.
3.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.
| 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 |
In response to your entry, init reads the inittab file and follows the instructions that correspond to the
change in run level.
Alternatively, you can reboot the system by using one of the following
commands:
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
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.
3.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
3.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.
# /usr/sbin/shutdown -r now
# /sbin/reboot
3.5.2.3 Reexamining the inittab File
To reexamine the inittab file, enter the init command with the q argument, as follows:
# init q
getty(8)
reference page for further information about the relationship
between terminal lines and the init command.
3.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.
3.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.
3.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.
| 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) |
To set the date to 09:34:00 AM Jan 7, 2000 using the mmddHHMM[[cc]yy][.ss] Digital format:
# date 010709342000 # date 0107093400.00 # date 010709342000.00
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
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 can fail for the following reasons:
Refer to Section 3.3 or your system's hardware guide
for instructions on specifying the correct boot path.
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
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
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.
There are several good reasons to stop the system in a controlled shutdown.
For example:
In each of these and similar situations a variety of options are available
to you. Regardless of how you decide to resolve the situation, your first
step is to initiate a controlled shutdown of the system. There are practical
and reasonable ways to shut down your system from single-user mode or multiuser
mode.
A system that has panicked or crashed presents you with a different
set of circumstances than a system that has shut down in an orderly fashion.
However, this chapter discusses orderly shutdowns only.
The following sections describe typical shutdown operations and provide
examples of what happens when you use the command flags. Refer to the
shutdown time [warning-message]
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.
shutdown -h time [warning-message]
shutdown -r time [warning-message]
date(1) reference page for more information.
3.8 Resolving Booting Problems
Should your system not boot, the following list suggests some areas
for further investigation:
kdbx(8) or dbx(1) reference pages for more information.
Refer to Section 3.3.1 for information on booting an
alternate kernel.fsck(8) reference page for more information. If you
have an Advanced File System (AdvFS), disk corruption is very unlikely.
3.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.
3.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:
shutdown(8)
reference page for more information.
3.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:
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:
# cd /
# 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.
3.10.2 Shutting Down and Halting the System
To shut down the system from multiuser mode, warn all users, and halt
all systems:
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:
# cd /
# 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.
3.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:
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:
# cd /
# 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.
3.10.4 Shutting Down and Halting Systems Immediately
To shut down and halt the system immediately:
In response to this command, the system shuts down immediately
and halts the system.
# cd /
# shutdown -h now
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.
3.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.