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.
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 Tru64 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.
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
ededitor, you must change the protections of the root file system to read-write. At the prompt, enter the following command:#mount -u /
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:
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.
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.
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.
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 3.3
for more information on setting the default boot action for your system.
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.
Enter the boot command that corresponds to the desired startup mode.
Refer to Section 3.3 for the commands and procedures required to boot your 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:
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.
Enter the boot command that corresponds to the desired startup mode.
Refer to Section 3.3 for the commands and procedures required to boot your system.
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:
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.
When you are ready to go to multiuser mode, press Ctrl/d. Refer to Section 3.3 for the commands and procedures required to boot your system.
If your system crashes and is unable to recover automatically and reboot itself, follow these steps to prepare to boot the system:
Confirm that the hardware and all peripheral devices are connected.
Power up the hardware, if necessary. Always power up peripherals and devices before the processor.
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 Compaq 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.
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.
Enter the required boot command.
Refer to Section 3.3 for the commands and procedures required to boot your 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
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.
| Variable | Action |
boot_reset |
When set to
on, resets
the hardware on boot |
boot_osflags |
A combination of flags used to control the boot loader and kernel |
bootdef_dev |
Identifies the boot device |
boot_file |
Identifies the kernel to boot (on DEC 4000 and DEC 7000 processors) |
cpu_enable |
Selectively enables particular processors from the console |
To prepare the hardware:
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.
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
For DEC 3000 processors, set the time to wait to reset the SCSI device before booting:
>>>set scsi_reset 4
Use the following procedure to set the
boot_osflags
variable and the boot device:
Determine which options to the
boot_osflags
variable you want.
Table 3-2
lists the options.
| 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 ""
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:
Identify the slot number of the PMAZB or PMAZC option card:
>>>show conf
The previous command displays the system configuration.
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.
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"
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 Configuration and Tuning
guide for information.
After you have set the console variables, use the following command to boot the system:
>>>b
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
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
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 |
| Specifies the console mode |
The
inittab
file contains line
entries that define the specific run levels and the run command scripts that
are associated with the run level.
When the
init
process
starts, it reads the
inittab
file and executes the relevant
run command scripts.
The scripts, in turn, define which processes are to
run (and which processes are to be killed if the system is changing from one
level to another) at a specific run level.
Refer to the
init(8)
and
inittab(4)
reference pages and to
Chapter 4
for information
about reading and modifying the
inittab
file.
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.
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.
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 |
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.
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
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.
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 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.
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.
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.
The system has an internal clock that you set when you install the system. The clock maintains the time and date whether the power is on or off. Nevertheless, there are occasions when you might need to reset the time or date. For example, with battery-powered clocks, you might need to reset the time as a result of battery failure; or you may need to synchronize system time with standard time.
To set the date and time, log in as root and use the following syntax
with the
date
command:
date
[[cc]yy]mmddHHMM[.ss]
| 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] 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
date(1)
reference page for more information.
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 3.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 3.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.
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
dxshutdowncommand 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.
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:
Runs the
wall
program to notify all users
of the impending shutdown
Disables new logins
Stops all accounting and error-logging processes
Runs the
killall
program to stop all other
processes
Runs the
sync
program to synchronize the
disk(s)
Logs the shutdown in the log file
Unmounts file systems
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.
To shut down the system from multiuser mode to single-user mode at a specific time and warn users of the shutdown:
Log in as root and change to the root directory:
#cd /
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.
To shut down the system from multiuser mode, warn all users, and halt all systems:
Log in as root and change to the root directory:
#cd /
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.
To shut down the system from multiuser mode, warn all users, and automatically reboot the system to multiuser mode:
Log in as root and change to the root directory:
#cd /
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
fsckfinds file system inconsistencies, it displays a warning message, recommending that you runfsckagain from single-user mode before operating the system in multiuser mode.
To shut down and halt the system immediately:
Log in as root and change to the root directory. For example, enter the following command:
#cd /
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.
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.