NAME
reboot, halt, fastboot, fasthalt – stopping and restarting the system
SYNOPSIS
halt [-DflNnpq] [-e variable=value] [-k kernel] [-o options]
reboot [-cDdflNnpqr] [-e variable=value] [-k kernel] [-o options]
fasthalt [-DflNnpq] [-e variable=value] [-k kernel] [-o options]
fastboot [-dDflNnpq] [-e variable=value] [-k kernel] [-o options]
DESCRIPTION
The halt and reboot utilities stop and restart the system, respectively.
Both utilities have two distinct modes of operation. In normal mode, they send a signal to the init(8) process, which shuts down running services and stops or restarts the system. In fast mode, they flush the file system cache to disk, send all running processes a SIGTERM (and subsequently a SIGKILL) and stop or restart the system themselves. Services are killed, not shut down, which may result in data loss.
In either mode, the action is logged, including entering a shutdown record into the user accounting database.
The following options are available:
- -c
-
The system will turn off the power and then turn it back on if it can. If the power down action fails, the system will halt or reboot normally, depending on whether halt or reboot was called. At the present time, only the ipmi(4) driver implements the power cycle functionality and only on hardware with a BMC that supports power cycling. Unlike power off, the amount of hardware that supports power cycling is small.
- -D
-
Delete existing nextboot configuration and exit.
- -d
-
The system is requested to create a crash dump. This option is supported only when rebooting, and it has no effect unless a dump device has previously been specified with dumpon(8).
- -e variable=value
-
Sets variable to value in the loader's and kernel's environment. If value is not already enclosed in double quotes, they will be added before writing to the nextboot configuration. Care should be taken if value contains any characters that are special to the shell or loader's configuration parsing code.
- -f
-
Forced mode. Normally, halt or reboot checks for the presence of the next kernel, and absence of the /var/run/noshutdown file. Without this flag, the operation is rejected if one of these checks fails.
- -k kname
-
Boot the specified kernel kname on the next system boot. This is a one-shot option, the default kernel will be booted on successive boots. No reboot or halt will be performed if /boot/kname/kernel does not exist unless the -f flag is specified.
- -l
-
The halt or reboot is not logged to the system log. This option is intended for applications such as shutdown(8), that call reboot or halt and log this themselves.
- -N
-
The file system cache is not flushed during the initial process clean-up, however the kernel level reboot(2) is still processed with a sync. This option can be useful for performing a “best-effort” reboot when devices might be unavailable. This can happen when devices have been disconnected, such as with iscsi(4).
- -n
-
The file system cache is not flushed. This option should probably not be used.
- -o options
-
This option allows the passing of kernel flags for the next boot.
- -p
-
The system will turn off the power if it can. If the power down action fails, the system will halt or reboot normally, depending on whether halt or reboot was called.
- -q
-
The system is halted or restarted quickly and ungracefully, and only the flushing of the file system cache is performed (if the -n option is not specified). This option should probably not be used.
- -r
-
The system kills all processes, unmounts all filesystems, mounts the new root filesystem, and begins the usual startup sequence. After changing vfs.root.mountfrom with kenv(1), reboot -r can be used to change the root filesystem while preserving kernel state. This requires the tmpfs(4) kernel module to be loaded because init(8) needs a place to store itself after the old root is unmounted, but before the new root is in place.
The fasthalt and fastboot utilities invoke halt and reboot, respectively, in fast mode.
The shutdown(8) utility can be used to not only stop or restart the system right away, but also schedule a stop or restart in the future, and will, unlike halt and reboot, give users advance warning of their impending doom.
EXAMPLES
Replace current root filesystem with UFS mounted from /dev/ada0s1a:
kenv vfs.root.mountfrom=ufs:/dev/ada0s1a reboot -r
This mechanism can also be used with NFS, with a caveat that it only works with NFSv4, and requires a numeric IPv4 address:
kenv vfs.root.mountfrom=nfs:192.168.1.1:/share/name reboot -r
SEE ALSO
kenv(1), reboot(2), getutxent(3), ipmi(4), boot(8), dumpon(8), nextboot(8), savecore(8), shutdown(8), sync(8)
HISTORY
A reboot utility appeared in 4.0BSD.
Historically, the shutdown(8) utility was used when the system needed to be halted or restarted cleanly in the normal course of operations, and the halt and reboot utilities were blunt instruments used only in single-user mode or if exceptional circumstances made a normal shutdown impractical. As other operating systems did away with this distinction, and it became clear that many users were unaware of it and were using reboot in the belief that it performed a clean shutdown, it was rewritten to conform to that expectation.