What is the difference between these commands for bringing down a Linux server?
Clash Royale CLAN TAG#URR8PPP
up vote
59
down vote
favorite
Reading "What is the difference between Halt and Shutdown commands?" , I generally have an idea what does the command shutdown does, with or without -h/-r options.
The "halt" command performs power off of the system to run-level 0 of
the system.
The "shutdown" command performs a power off of the system to run-level
1 without -h or -r command.
What about the command "poweroff" does it goes into run-level 0 or 1 ?
Is this the only main difference between these three commands?
rhel shutdown
add a comment |Â
up vote
59
down vote
favorite
Reading "What is the difference between Halt and Shutdown commands?" , I generally have an idea what does the command shutdown does, with or without -h/-r options.
The "halt" command performs power off of the system to run-level 0 of
the system.
The "shutdown" command performs a power off of the system to run-level
1 without -h or -r command.
What about the command "poweroff" does it goes into run-level 0 or 1 ?
Is this the only main difference between these three commands?
rhel shutdown
Related askubuntu.com/q/578144/216503
â heemayl
Apr 13 '15 at 13:36
This is some of the things that differ significantly for e.g. Solaris and FreeBSD. (There they usually (almost) immediately halt / shutdown the server, without changing runlevels to shut down stuff first)
â Gert van den Berg
Jan 4 '17 at 12:52
add a comment |Â
up vote
59
down vote
favorite
up vote
59
down vote
favorite
Reading "What is the difference between Halt and Shutdown commands?" , I generally have an idea what does the command shutdown does, with or without -h/-r options.
The "halt" command performs power off of the system to run-level 0 of
the system.
The "shutdown" command performs a power off of the system to run-level
1 without -h or -r command.
What about the command "poweroff" does it goes into run-level 0 or 1 ?
Is this the only main difference between these three commands?
rhel shutdown
Reading "What is the difference between Halt and Shutdown commands?" , I generally have an idea what does the command shutdown does, with or without -h/-r options.
The "halt" command performs power off of the system to run-level 0 of
the system.
The "shutdown" command performs a power off of the system to run-level
1 without -h or -r command.
What about the command "poweroff" does it goes into run-level 0 or 1 ?
Is this the only main difference between these three commands?
rhel shutdown
rhel shutdown
edited May 5 '17 at 23:44
Jeff Schaller
32.6k849110
32.6k849110
asked Apr 13 '15 at 8:34
Win.T
4721612
4721612
Related askubuntu.com/q/578144/216503
â heemayl
Apr 13 '15 at 13:36
This is some of the things that differ significantly for e.g. Solaris and FreeBSD. (There they usually (almost) immediately halt / shutdown the server, without changing runlevels to shut down stuff first)
â Gert van den Berg
Jan 4 '17 at 12:52
add a comment |Â
Related askubuntu.com/q/578144/216503
â heemayl
Apr 13 '15 at 13:36
This is some of the things that differ significantly for e.g. Solaris and FreeBSD. (There they usually (almost) immediately halt / shutdown the server, without changing runlevels to shut down stuff first)
â Gert van den Berg
Jan 4 '17 at 12:52
Related askubuntu.com/q/578144/216503
â heemayl
Apr 13 '15 at 13:36
Related askubuntu.com/q/578144/216503
â heemayl
Apr 13 '15 at 13:36
This is some of the things that differ significantly for e.g. Solaris and FreeBSD. (There they usually (almost) immediately halt / shutdown the server, without changing runlevels to shut down stuff first)
â Gert van den Berg
Jan 4 '17 at 12:52
This is some of the things that differ significantly for e.g. Solaris and FreeBSD. (There they usually (almost) immediately halt / shutdown the server, without changing runlevels to shut down stuff first)
â Gert van den Berg
Jan 4 '17 at 12:52
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
107
down vote
accepted
And now, the systemd answer.
You're using, per the tag on your question, Red Hat Enterprise Linux. Since version 7, that has used systemd. None of the other answers are correct for the world of systemd; nor even are some of the assumptions in your question.
Forget about runlevels; they exist, but only as compatibility shims. The systemd documentation states that the concept is "obsolete". If you're starting to learn this stuff on a systemd operating system, don't start there.- Forget about the manual page that marcelm quoted; it's not from the right toolset at all, and is a description of another toolset's command, incorrect for systemd's. It's the one for the
halt
command from the van Smoorenburg "System 5"init
utilities. - Ignore the statements that
/sbin/halt
is a symbolic link to/sbin/reboot
; that's not true with systemd. There is no separatereboot
program at all. - Ignore the statements that
halt
orreboot
invoke ashutdown
program with command-line arguments; they are also not true with systemd. There is no separateshutdown
program at all.
Every system management toolset has its version of these utilities. systemd, upstart, nosh, van Smoorenburg init
, and BSD init
all have their own halt
, poweroff
, and so forth. On each their mechanics are slightly different. So are their manual pages.
In the systemd toolset halt
,poweroff
,reboot
, telinit
, and shutdown
are all symbolic links to /bin/systemctl
. They are all backwards compatibility shims, that are simply shorthands for invoking systemd's primary command-line interface: systemctl
. They all map to (and in fact are) that same single program. (By convention, the shell tells it which name it has been invoked by.)
targets, not runlevels
Most of those commands are shorthands for telling systemd, using systemctl
, to isolate a particular target. Isolation is explained in the systemctl
manual page (q.v.), but can be, for the purposes of this answer, thought of as starting a target and stopping any others. The standard targets used in systemd are listed on the systemd.special
(8) manual page.
The diagrams on the bootup
(7) manual page in the systemd toolset, in particular the last one, show that there are three "final" targets that are relevant here:
halt.target
â Once the system has reached the state of fully isolating this target, it will have called thereboot(RB_HALT_SYSTEM)
system call. The kernel will have attempted to enter a ROM monitor program, or simply halted the CPU (using whatever mechanism is appropriate for doing so).reboot.target
â Once the system has reached the state of fully isolating this target, it will have called thereboot(RB_AUTOBOOT)
system call (or the equivalent with the magic command line). The kernel will have attempted to trigger a reboot.poweroff.target
â Once the system has reached the state of fully isolating this target, it will have called thereboot(RB_POWER_OFF)
system call. The kernel will have attempted to remove power from the system, if possible.
These are the things that you should be thinking about as the final system states, not run levels. Notice from the diagram that the systemd target system itself encodes things that are, in other systems, implicit rather than explicit: such as the notion that each of these final targets encompasses the shutdown.target
target, so that one describes services that must be stopped before shutdown by having them conflict with the shutdown.target
target.
systemctl
tries to send requests to systemd-logind
when the calling user is not the superuser. It also passes delayed shutdowns over to systemd-shutdownd
. And some shorthands trigger wall
notifications. Those complexities aside, which would make this answer several times longer, assuming that you are currently the superuser and not requesting a scheduled action:
systemctl isolate halt.target
has the shorthands:shutdown -H now
systemctl halt
- plain unadorned
halt
systemctl isolate reboot.target
has the shorthands:shutdown -r now
telinit 6
systemctl reboot
- plain unadorned
reboot
systemctl isolate poweroff.target
has the shorthands:shutdown -P now
telinit 0
shutdown now
systemctl poweroff
- plain unadorned
poweroff
systemctl isolate rescue.target
has the shorthands:telinit 1
systemctl rescue
systemctl isolate multi-user.target
has the shorthands:telinit 2
telinit 3
telinit 4
systemctl isolate graphical.target
has the shorthand:telinit 5
After parsing the various differing command-line syntaxes, these all eventually end up in the same code paths inside the systemctl
program.
Notes:
- The traditional behaviour of option-less
shutdown now
has been to switch to single-user mode. This is not the case with systemd.rescue.target
â single-user mode being renamed rescue mode in systemd â is not reachable with theshutdown
command. telinit
really does wholly ignore all of thoserunlevelN.target
anddefault.target
symbolic links in the filesystem that the manual pages describe. The aforegiven mappings are hardwired into thesystemctl
program, in a table.- systemd has no notion of a current run level. The operation of these commands is not conditional upon any "if you are in run-level N".
- The
--force
option to thehalt
,reboot
, andpoweroff
commands is the same as saying--force --force
to thesystemctl halt
,systemctl reboot
, andsystemctl poweroff
commands. This makessystemctl
try to callreboot()
directly. Normally it just tries to isolate targets. telinit
is not the same asinit
. They are different programs in the systemd world, the latter being another name for thesystemd
program, not for thesystemctl
program. Thesystemd
program is not necessarily compiled with any van Smoorenburg compatibility at all, and on some systemd operating systems complains about being invoked incorrectly if one attemptsinit N
.
Further reading
- Are there any good reasons for halting system without cutting power?
- Why does `init 0` result in "Excess Arguments" on Arch install?
- Stephen Wadeley (2014). "8. Managing Services with systemd" Red Hat Enterprise Linux 7 System Administrators' Guide. Red Hat.
- Lennart Poettering (2013-10-07).
systemctl
. systemd manual pages. freedesktop.org. - Lennart Poettering (2013-10-07).
systemd.special
. systemd manual pages. freedesktop.org. - Lennart Poettering (2013-10-07).
bootup
. systemd manual pages. freedesktop.org. - Jonathan de Boyne Pollard (2018).
init
. nosh Guide. Softwares.
1
This is very much generic for most modern Linux systems so for instance answers wiert.me/2012/12/30/⦠After all these years wondering, I finally understand what's going on and why.
â Jeroen Wiert Pluimers
Sep 10 '16 at 15:17
systemctl reboot
should be equivalent tosystemctl start reboot.target --job-mode=replace-irreversible
. Using any other job mode is less robust. unix.stackexchange.com/questions/381739/â¦
â sourcejedi
Aug 3 '17 at 14:47
I read your entire reponse, and absorbed what I could. One question remains, the same one i came here for, issystemctl reboot
the "safe" way to reboot, e.g.init 6
which is the way we would otherwise safe reboot?
â Brian Thomas
Aug 17 at 21:19
add a comment |Â
up vote
23
down vote
halt
instructs the hardware to stop all CPU functions, but leaves it in a powered-on state. This usually means someone has to reboot or shut the machine down manually by pressing the power button afterwards. The specific way to achieve this is architecture specific, but for instance the x86 instruction set provides theHLT
instructions which halts the central processing unit (CPU) until the next external interrupt is fired.poweroff
, likehalt
, stops the CPU but also sends an ACPI hardware signal which will instruct the system to commence with a complete and immediate shutdown. This is roughly equivalent to pressing the power button on a typical desktop computer.
Both halt
and poweroff
are usually symbolic links to the reboot
executable, which will usually invoke the shutdown
tool with the appropriate arguments (-h
, -P
or r
) depending on if halt
, poweroff
or reboot
was used to invoke the tool. However, When the --force
option is passed to reboot
, or when in runlevel 0 or 6, reboot
will invoke the reboot()
system call with an appropriate command code itself.
Thomas, thank you very much for explaining. I am interested to know what about doing a #init 0, there is not much differences right?
â Win.T
Apr 13 '15 at 9:41
@Win.T Switching to runlevel 0 using e.g./sbin/init 0
or/sbin/telinit 0
should be the same as halting the system, although the specific steps taken would depend on the init system in question, such as System-V init, upstart or systemd. If you're running RHEL, you would be using systemd.
â Thomas Nyman
Apr 13 '15 at 10:08
3
Note to self: every time someone complains about an arcane Win32 API call, show them reboot(2).
â immibis
Apr 13 '15 at 12:29
@immibis But reboot is purposely arcane. It requires the magic flags so that it is very difficult to do by accident.
â Kevin Cox
Apr 2 '16 at 15:12
3
@KevinCox That's the argument for requiring magic flags. It's not the argument for accepting 4 different values for magic2, nor for behaving differently inside a PID namespace, nor for lumping several barely-related operations (like setting reboot-on-Ctrl-Alt-Delete behaviour) into one function.
â immibis
Apr 2 '16 at 22:10
add a comment |Â
up vote
3
down vote
halt
, poweroff
and shutdown -h
are completely equivalent. In fact, halt and poweroff do nothing but call shutdown -h
. From the halt/poweroff manpage:
If halt or reboot is called when the system is not in runlevel 0 or 6, in other words when it's running normally, shutdown will be invoked instead (with the -h or -r flag). For more info see the shutdown(8) manpage.
Shutdown then proceeds to shut down the system by switching to runlevel 0.
Halt and poweroff (and reboot) perform a dual role; when executed in the process of shutting down (i.e., in runlevel 0 or 6), they perform the low-level operations required to physically stop, power off, or reboot the machine, as described in another answer.
2
Which version of RHEL are you using? There normally is a difference between halt and poweroff (although for a while it used not to be the case in many distributions, but that was a bug).
â Bruno
Apr 13 '15 at 17:37
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
107
down vote
accepted
And now, the systemd answer.
You're using, per the tag on your question, Red Hat Enterprise Linux. Since version 7, that has used systemd. None of the other answers are correct for the world of systemd; nor even are some of the assumptions in your question.
Forget about runlevels; they exist, but only as compatibility shims. The systemd documentation states that the concept is "obsolete". If you're starting to learn this stuff on a systemd operating system, don't start there.- Forget about the manual page that marcelm quoted; it's not from the right toolset at all, and is a description of another toolset's command, incorrect for systemd's. It's the one for the
halt
command from the van Smoorenburg "System 5"init
utilities. - Ignore the statements that
/sbin/halt
is a symbolic link to/sbin/reboot
; that's not true with systemd. There is no separatereboot
program at all. - Ignore the statements that
halt
orreboot
invoke ashutdown
program with command-line arguments; they are also not true with systemd. There is no separateshutdown
program at all.
Every system management toolset has its version of these utilities. systemd, upstart, nosh, van Smoorenburg init
, and BSD init
all have their own halt
, poweroff
, and so forth. On each their mechanics are slightly different. So are their manual pages.
In the systemd toolset halt
,poweroff
,reboot
, telinit
, and shutdown
are all symbolic links to /bin/systemctl
. They are all backwards compatibility shims, that are simply shorthands for invoking systemd's primary command-line interface: systemctl
. They all map to (and in fact are) that same single program. (By convention, the shell tells it which name it has been invoked by.)
targets, not runlevels
Most of those commands are shorthands for telling systemd, using systemctl
, to isolate a particular target. Isolation is explained in the systemctl
manual page (q.v.), but can be, for the purposes of this answer, thought of as starting a target and stopping any others. The standard targets used in systemd are listed on the systemd.special
(8) manual page.
The diagrams on the bootup
(7) manual page in the systemd toolset, in particular the last one, show that there are three "final" targets that are relevant here:
halt.target
â Once the system has reached the state of fully isolating this target, it will have called thereboot(RB_HALT_SYSTEM)
system call. The kernel will have attempted to enter a ROM monitor program, or simply halted the CPU (using whatever mechanism is appropriate for doing so).reboot.target
â Once the system has reached the state of fully isolating this target, it will have called thereboot(RB_AUTOBOOT)
system call (or the equivalent with the magic command line). The kernel will have attempted to trigger a reboot.poweroff.target
â Once the system has reached the state of fully isolating this target, it will have called thereboot(RB_POWER_OFF)
system call. The kernel will have attempted to remove power from the system, if possible.
These are the things that you should be thinking about as the final system states, not run levels. Notice from the diagram that the systemd target system itself encodes things that are, in other systems, implicit rather than explicit: such as the notion that each of these final targets encompasses the shutdown.target
target, so that one describes services that must be stopped before shutdown by having them conflict with the shutdown.target
target.
systemctl
tries to send requests to systemd-logind
when the calling user is not the superuser. It also passes delayed shutdowns over to systemd-shutdownd
. And some shorthands trigger wall
notifications. Those complexities aside, which would make this answer several times longer, assuming that you are currently the superuser and not requesting a scheduled action:
systemctl isolate halt.target
has the shorthands:shutdown -H now
systemctl halt
- plain unadorned
halt
systemctl isolate reboot.target
has the shorthands:shutdown -r now
telinit 6
systemctl reboot
- plain unadorned
reboot
systemctl isolate poweroff.target
has the shorthands:shutdown -P now
telinit 0
shutdown now
systemctl poweroff
- plain unadorned
poweroff
systemctl isolate rescue.target
has the shorthands:telinit 1
systemctl rescue
systemctl isolate multi-user.target
has the shorthands:telinit 2
telinit 3
telinit 4
systemctl isolate graphical.target
has the shorthand:telinit 5
After parsing the various differing command-line syntaxes, these all eventually end up in the same code paths inside the systemctl
program.
Notes:
- The traditional behaviour of option-less
shutdown now
has been to switch to single-user mode. This is not the case with systemd.rescue.target
â single-user mode being renamed rescue mode in systemd â is not reachable with theshutdown
command. telinit
really does wholly ignore all of thoserunlevelN.target
anddefault.target
symbolic links in the filesystem that the manual pages describe. The aforegiven mappings are hardwired into thesystemctl
program, in a table.- systemd has no notion of a current run level. The operation of these commands is not conditional upon any "if you are in run-level N".
- The
--force
option to thehalt
,reboot
, andpoweroff
commands is the same as saying--force --force
to thesystemctl halt
,systemctl reboot
, andsystemctl poweroff
commands. This makessystemctl
try to callreboot()
directly. Normally it just tries to isolate targets. telinit
is not the same asinit
. They are different programs in the systemd world, the latter being another name for thesystemd
program, not for thesystemctl
program. Thesystemd
program is not necessarily compiled with any van Smoorenburg compatibility at all, and on some systemd operating systems complains about being invoked incorrectly if one attemptsinit N
.
Further reading
- Are there any good reasons for halting system without cutting power?
- Why does `init 0` result in "Excess Arguments" on Arch install?
- Stephen Wadeley (2014). "8. Managing Services with systemd" Red Hat Enterprise Linux 7 System Administrators' Guide. Red Hat.
- Lennart Poettering (2013-10-07).
systemctl
. systemd manual pages. freedesktop.org. - Lennart Poettering (2013-10-07).
systemd.special
. systemd manual pages. freedesktop.org. - Lennart Poettering (2013-10-07).
bootup
. systemd manual pages. freedesktop.org. - Jonathan de Boyne Pollard (2018).
init
. nosh Guide. Softwares.
1
This is very much generic for most modern Linux systems so for instance answers wiert.me/2012/12/30/⦠After all these years wondering, I finally understand what's going on and why.
â Jeroen Wiert Pluimers
Sep 10 '16 at 15:17
systemctl reboot
should be equivalent tosystemctl start reboot.target --job-mode=replace-irreversible
. Using any other job mode is less robust. unix.stackexchange.com/questions/381739/â¦
â sourcejedi
Aug 3 '17 at 14:47
I read your entire reponse, and absorbed what I could. One question remains, the same one i came here for, issystemctl reboot
the "safe" way to reboot, e.g.init 6
which is the way we would otherwise safe reboot?
â Brian Thomas
Aug 17 at 21:19
add a comment |Â
up vote
107
down vote
accepted
And now, the systemd answer.
You're using, per the tag on your question, Red Hat Enterprise Linux. Since version 7, that has used systemd. None of the other answers are correct for the world of systemd; nor even are some of the assumptions in your question.
Forget about runlevels; they exist, but only as compatibility shims. The systemd documentation states that the concept is "obsolete". If you're starting to learn this stuff on a systemd operating system, don't start there.- Forget about the manual page that marcelm quoted; it's not from the right toolset at all, and is a description of another toolset's command, incorrect for systemd's. It's the one for the
halt
command from the van Smoorenburg "System 5"init
utilities. - Ignore the statements that
/sbin/halt
is a symbolic link to/sbin/reboot
; that's not true with systemd. There is no separatereboot
program at all. - Ignore the statements that
halt
orreboot
invoke ashutdown
program with command-line arguments; they are also not true with systemd. There is no separateshutdown
program at all.
Every system management toolset has its version of these utilities. systemd, upstart, nosh, van Smoorenburg init
, and BSD init
all have their own halt
, poweroff
, and so forth. On each their mechanics are slightly different. So are their manual pages.
In the systemd toolset halt
,poweroff
,reboot
, telinit
, and shutdown
are all symbolic links to /bin/systemctl
. They are all backwards compatibility shims, that are simply shorthands for invoking systemd's primary command-line interface: systemctl
. They all map to (and in fact are) that same single program. (By convention, the shell tells it which name it has been invoked by.)
targets, not runlevels
Most of those commands are shorthands for telling systemd, using systemctl
, to isolate a particular target. Isolation is explained in the systemctl
manual page (q.v.), but can be, for the purposes of this answer, thought of as starting a target and stopping any others. The standard targets used in systemd are listed on the systemd.special
(8) manual page.
The diagrams on the bootup
(7) manual page in the systemd toolset, in particular the last one, show that there are three "final" targets that are relevant here:
halt.target
â Once the system has reached the state of fully isolating this target, it will have called thereboot(RB_HALT_SYSTEM)
system call. The kernel will have attempted to enter a ROM monitor program, or simply halted the CPU (using whatever mechanism is appropriate for doing so).reboot.target
â Once the system has reached the state of fully isolating this target, it will have called thereboot(RB_AUTOBOOT)
system call (or the equivalent with the magic command line). The kernel will have attempted to trigger a reboot.poweroff.target
â Once the system has reached the state of fully isolating this target, it will have called thereboot(RB_POWER_OFF)
system call. The kernel will have attempted to remove power from the system, if possible.
These are the things that you should be thinking about as the final system states, not run levels. Notice from the diagram that the systemd target system itself encodes things that are, in other systems, implicit rather than explicit: such as the notion that each of these final targets encompasses the shutdown.target
target, so that one describes services that must be stopped before shutdown by having them conflict with the shutdown.target
target.
systemctl
tries to send requests to systemd-logind
when the calling user is not the superuser. It also passes delayed shutdowns over to systemd-shutdownd
. And some shorthands trigger wall
notifications. Those complexities aside, which would make this answer several times longer, assuming that you are currently the superuser and not requesting a scheduled action:
systemctl isolate halt.target
has the shorthands:shutdown -H now
systemctl halt
- plain unadorned
halt
systemctl isolate reboot.target
has the shorthands:shutdown -r now
telinit 6
systemctl reboot
- plain unadorned
reboot
systemctl isolate poweroff.target
has the shorthands:shutdown -P now
telinit 0
shutdown now
systemctl poweroff
- plain unadorned
poweroff
systemctl isolate rescue.target
has the shorthands:telinit 1
systemctl rescue
systemctl isolate multi-user.target
has the shorthands:telinit 2
telinit 3
telinit 4
systemctl isolate graphical.target
has the shorthand:telinit 5
After parsing the various differing command-line syntaxes, these all eventually end up in the same code paths inside the systemctl
program.
Notes:
- The traditional behaviour of option-less
shutdown now
has been to switch to single-user mode. This is not the case with systemd.rescue.target
â single-user mode being renamed rescue mode in systemd â is not reachable with theshutdown
command. telinit
really does wholly ignore all of thoserunlevelN.target
anddefault.target
symbolic links in the filesystem that the manual pages describe. The aforegiven mappings are hardwired into thesystemctl
program, in a table.- systemd has no notion of a current run level. The operation of these commands is not conditional upon any "if you are in run-level N".
- The
--force
option to thehalt
,reboot
, andpoweroff
commands is the same as saying--force --force
to thesystemctl halt
,systemctl reboot
, andsystemctl poweroff
commands. This makessystemctl
try to callreboot()
directly. Normally it just tries to isolate targets. telinit
is not the same asinit
. They are different programs in the systemd world, the latter being another name for thesystemd
program, not for thesystemctl
program. Thesystemd
program is not necessarily compiled with any van Smoorenburg compatibility at all, and on some systemd operating systems complains about being invoked incorrectly if one attemptsinit N
.
Further reading
- Are there any good reasons for halting system without cutting power?
- Why does `init 0` result in "Excess Arguments" on Arch install?
- Stephen Wadeley (2014). "8. Managing Services with systemd" Red Hat Enterprise Linux 7 System Administrators' Guide. Red Hat.
- Lennart Poettering (2013-10-07).
systemctl
. systemd manual pages. freedesktop.org. - Lennart Poettering (2013-10-07).
systemd.special
. systemd manual pages. freedesktop.org. - Lennart Poettering (2013-10-07).
bootup
. systemd manual pages. freedesktop.org. - Jonathan de Boyne Pollard (2018).
init
. nosh Guide. Softwares.
1
This is very much generic for most modern Linux systems so for instance answers wiert.me/2012/12/30/⦠After all these years wondering, I finally understand what's going on and why.
â Jeroen Wiert Pluimers
Sep 10 '16 at 15:17
systemctl reboot
should be equivalent tosystemctl start reboot.target --job-mode=replace-irreversible
. Using any other job mode is less robust. unix.stackexchange.com/questions/381739/â¦
â sourcejedi
Aug 3 '17 at 14:47
I read your entire reponse, and absorbed what I could. One question remains, the same one i came here for, issystemctl reboot
the "safe" way to reboot, e.g.init 6
which is the way we would otherwise safe reboot?
â Brian Thomas
Aug 17 at 21:19
add a comment |Â
up vote
107
down vote
accepted
up vote
107
down vote
accepted
And now, the systemd answer.
You're using, per the tag on your question, Red Hat Enterprise Linux. Since version 7, that has used systemd. None of the other answers are correct for the world of systemd; nor even are some of the assumptions in your question.
Forget about runlevels; they exist, but only as compatibility shims. The systemd documentation states that the concept is "obsolete". If you're starting to learn this stuff on a systemd operating system, don't start there.- Forget about the manual page that marcelm quoted; it's not from the right toolset at all, and is a description of another toolset's command, incorrect for systemd's. It's the one for the
halt
command from the van Smoorenburg "System 5"init
utilities. - Ignore the statements that
/sbin/halt
is a symbolic link to/sbin/reboot
; that's not true with systemd. There is no separatereboot
program at all. - Ignore the statements that
halt
orreboot
invoke ashutdown
program with command-line arguments; they are also not true with systemd. There is no separateshutdown
program at all.
Every system management toolset has its version of these utilities. systemd, upstart, nosh, van Smoorenburg init
, and BSD init
all have their own halt
, poweroff
, and so forth. On each their mechanics are slightly different. So are their manual pages.
In the systemd toolset halt
,poweroff
,reboot
, telinit
, and shutdown
are all symbolic links to /bin/systemctl
. They are all backwards compatibility shims, that are simply shorthands for invoking systemd's primary command-line interface: systemctl
. They all map to (and in fact are) that same single program. (By convention, the shell tells it which name it has been invoked by.)
targets, not runlevels
Most of those commands are shorthands for telling systemd, using systemctl
, to isolate a particular target. Isolation is explained in the systemctl
manual page (q.v.), but can be, for the purposes of this answer, thought of as starting a target and stopping any others. The standard targets used in systemd are listed on the systemd.special
(8) manual page.
The diagrams on the bootup
(7) manual page in the systemd toolset, in particular the last one, show that there are three "final" targets that are relevant here:
halt.target
â Once the system has reached the state of fully isolating this target, it will have called thereboot(RB_HALT_SYSTEM)
system call. The kernel will have attempted to enter a ROM monitor program, or simply halted the CPU (using whatever mechanism is appropriate for doing so).reboot.target
â Once the system has reached the state of fully isolating this target, it will have called thereboot(RB_AUTOBOOT)
system call (or the equivalent with the magic command line). The kernel will have attempted to trigger a reboot.poweroff.target
â Once the system has reached the state of fully isolating this target, it will have called thereboot(RB_POWER_OFF)
system call. The kernel will have attempted to remove power from the system, if possible.
These are the things that you should be thinking about as the final system states, not run levels. Notice from the diagram that the systemd target system itself encodes things that are, in other systems, implicit rather than explicit: such as the notion that each of these final targets encompasses the shutdown.target
target, so that one describes services that must be stopped before shutdown by having them conflict with the shutdown.target
target.
systemctl
tries to send requests to systemd-logind
when the calling user is not the superuser. It also passes delayed shutdowns over to systemd-shutdownd
. And some shorthands trigger wall
notifications. Those complexities aside, which would make this answer several times longer, assuming that you are currently the superuser and not requesting a scheduled action:
systemctl isolate halt.target
has the shorthands:shutdown -H now
systemctl halt
- plain unadorned
halt
systemctl isolate reboot.target
has the shorthands:shutdown -r now
telinit 6
systemctl reboot
- plain unadorned
reboot
systemctl isolate poweroff.target
has the shorthands:shutdown -P now
telinit 0
shutdown now
systemctl poweroff
- plain unadorned
poweroff
systemctl isolate rescue.target
has the shorthands:telinit 1
systemctl rescue
systemctl isolate multi-user.target
has the shorthands:telinit 2
telinit 3
telinit 4
systemctl isolate graphical.target
has the shorthand:telinit 5
After parsing the various differing command-line syntaxes, these all eventually end up in the same code paths inside the systemctl
program.
Notes:
- The traditional behaviour of option-less
shutdown now
has been to switch to single-user mode. This is not the case with systemd.rescue.target
â single-user mode being renamed rescue mode in systemd â is not reachable with theshutdown
command. telinit
really does wholly ignore all of thoserunlevelN.target
anddefault.target
symbolic links in the filesystem that the manual pages describe. The aforegiven mappings are hardwired into thesystemctl
program, in a table.- systemd has no notion of a current run level. The operation of these commands is not conditional upon any "if you are in run-level N".
- The
--force
option to thehalt
,reboot
, andpoweroff
commands is the same as saying--force --force
to thesystemctl halt
,systemctl reboot
, andsystemctl poweroff
commands. This makessystemctl
try to callreboot()
directly. Normally it just tries to isolate targets. telinit
is not the same asinit
. They are different programs in the systemd world, the latter being another name for thesystemd
program, not for thesystemctl
program. Thesystemd
program is not necessarily compiled with any van Smoorenburg compatibility at all, and on some systemd operating systems complains about being invoked incorrectly if one attemptsinit N
.
Further reading
- Are there any good reasons for halting system without cutting power?
- Why does `init 0` result in "Excess Arguments" on Arch install?
- Stephen Wadeley (2014). "8. Managing Services with systemd" Red Hat Enterprise Linux 7 System Administrators' Guide. Red Hat.
- Lennart Poettering (2013-10-07).
systemctl
. systemd manual pages. freedesktop.org. - Lennart Poettering (2013-10-07).
systemd.special
. systemd manual pages. freedesktop.org. - Lennart Poettering (2013-10-07).
bootup
. systemd manual pages. freedesktop.org. - Jonathan de Boyne Pollard (2018).
init
. nosh Guide. Softwares.
And now, the systemd answer.
You're using, per the tag on your question, Red Hat Enterprise Linux. Since version 7, that has used systemd. None of the other answers are correct for the world of systemd; nor even are some of the assumptions in your question.
Forget about runlevels; they exist, but only as compatibility shims. The systemd documentation states that the concept is "obsolete". If you're starting to learn this stuff on a systemd operating system, don't start there.- Forget about the manual page that marcelm quoted; it's not from the right toolset at all, and is a description of another toolset's command, incorrect for systemd's. It's the one for the
halt
command from the van Smoorenburg "System 5"init
utilities. - Ignore the statements that
/sbin/halt
is a symbolic link to/sbin/reboot
; that's not true with systemd. There is no separatereboot
program at all. - Ignore the statements that
halt
orreboot
invoke ashutdown
program with command-line arguments; they are also not true with systemd. There is no separateshutdown
program at all.
Every system management toolset has its version of these utilities. systemd, upstart, nosh, van Smoorenburg init
, and BSD init
all have their own halt
, poweroff
, and so forth. On each their mechanics are slightly different. So are their manual pages.
In the systemd toolset halt
,poweroff
,reboot
, telinit
, and shutdown
are all symbolic links to /bin/systemctl
. They are all backwards compatibility shims, that are simply shorthands for invoking systemd's primary command-line interface: systemctl
. They all map to (and in fact are) that same single program. (By convention, the shell tells it which name it has been invoked by.)
targets, not runlevels
Most of those commands are shorthands for telling systemd, using systemctl
, to isolate a particular target. Isolation is explained in the systemctl
manual page (q.v.), but can be, for the purposes of this answer, thought of as starting a target and stopping any others. The standard targets used in systemd are listed on the systemd.special
(8) manual page.
The diagrams on the bootup
(7) manual page in the systemd toolset, in particular the last one, show that there are three "final" targets that are relevant here:
halt.target
â Once the system has reached the state of fully isolating this target, it will have called thereboot(RB_HALT_SYSTEM)
system call. The kernel will have attempted to enter a ROM monitor program, or simply halted the CPU (using whatever mechanism is appropriate for doing so).reboot.target
â Once the system has reached the state of fully isolating this target, it will have called thereboot(RB_AUTOBOOT)
system call (or the equivalent with the magic command line). The kernel will have attempted to trigger a reboot.poweroff.target
â Once the system has reached the state of fully isolating this target, it will have called thereboot(RB_POWER_OFF)
system call. The kernel will have attempted to remove power from the system, if possible.
These are the things that you should be thinking about as the final system states, not run levels. Notice from the diagram that the systemd target system itself encodes things that are, in other systems, implicit rather than explicit: such as the notion that each of these final targets encompasses the shutdown.target
target, so that one describes services that must be stopped before shutdown by having them conflict with the shutdown.target
target.
systemctl
tries to send requests to systemd-logind
when the calling user is not the superuser. It also passes delayed shutdowns over to systemd-shutdownd
. And some shorthands trigger wall
notifications. Those complexities aside, which would make this answer several times longer, assuming that you are currently the superuser and not requesting a scheduled action:
systemctl isolate halt.target
has the shorthands:shutdown -H now
systemctl halt
- plain unadorned
halt
systemctl isolate reboot.target
has the shorthands:shutdown -r now
telinit 6
systemctl reboot
- plain unadorned
reboot
systemctl isolate poweroff.target
has the shorthands:shutdown -P now
telinit 0
shutdown now
systemctl poweroff
- plain unadorned
poweroff
systemctl isolate rescue.target
has the shorthands:telinit 1
systemctl rescue
systemctl isolate multi-user.target
has the shorthands:telinit 2
telinit 3
telinit 4
systemctl isolate graphical.target
has the shorthand:telinit 5
After parsing the various differing command-line syntaxes, these all eventually end up in the same code paths inside the systemctl
program.
Notes:
- The traditional behaviour of option-less
shutdown now
has been to switch to single-user mode. This is not the case with systemd.rescue.target
â single-user mode being renamed rescue mode in systemd â is not reachable with theshutdown
command. telinit
really does wholly ignore all of thoserunlevelN.target
anddefault.target
symbolic links in the filesystem that the manual pages describe. The aforegiven mappings are hardwired into thesystemctl
program, in a table.- systemd has no notion of a current run level. The operation of these commands is not conditional upon any "if you are in run-level N".
- The
--force
option to thehalt
,reboot
, andpoweroff
commands is the same as saying--force --force
to thesystemctl halt
,systemctl reboot
, andsystemctl poweroff
commands. This makessystemctl
try to callreboot()
directly. Normally it just tries to isolate targets. telinit
is not the same asinit
. They are different programs in the systemd world, the latter being another name for thesystemd
program, not for thesystemctl
program. Thesystemd
program is not necessarily compiled with any van Smoorenburg compatibility at all, and on some systemd operating systems complains about being invoked incorrectly if one attemptsinit N
.
Further reading
- Are there any good reasons for halting system without cutting power?
- Why does `init 0` result in "Excess Arguments" on Arch install?
- Stephen Wadeley (2014). "8. Managing Services with systemd" Red Hat Enterprise Linux 7 System Administrators' Guide. Red Hat.
- Lennart Poettering (2013-10-07).
systemctl
. systemd manual pages. freedesktop.org. - Lennart Poettering (2013-10-07).
systemd.special
. systemd manual pages. freedesktop.org. - Lennart Poettering (2013-10-07).
bootup
. systemd manual pages. freedesktop.org. - Jonathan de Boyne Pollard (2018).
init
. nosh Guide. Softwares.
edited Aug 19 at 11:33
answered Apr 13 '15 at 19:00
JdeBP
29.5k460136
29.5k460136
1
This is very much generic for most modern Linux systems so for instance answers wiert.me/2012/12/30/⦠After all these years wondering, I finally understand what's going on and why.
â Jeroen Wiert Pluimers
Sep 10 '16 at 15:17
systemctl reboot
should be equivalent tosystemctl start reboot.target --job-mode=replace-irreversible
. Using any other job mode is less robust. unix.stackexchange.com/questions/381739/â¦
â sourcejedi
Aug 3 '17 at 14:47
I read your entire reponse, and absorbed what I could. One question remains, the same one i came here for, issystemctl reboot
the "safe" way to reboot, e.g.init 6
which is the way we would otherwise safe reboot?
â Brian Thomas
Aug 17 at 21:19
add a comment |Â
1
This is very much generic for most modern Linux systems so for instance answers wiert.me/2012/12/30/⦠After all these years wondering, I finally understand what's going on and why.
â Jeroen Wiert Pluimers
Sep 10 '16 at 15:17
systemctl reboot
should be equivalent tosystemctl start reboot.target --job-mode=replace-irreversible
. Using any other job mode is less robust. unix.stackexchange.com/questions/381739/â¦
â sourcejedi
Aug 3 '17 at 14:47
I read your entire reponse, and absorbed what I could. One question remains, the same one i came here for, issystemctl reboot
the "safe" way to reboot, e.g.init 6
which is the way we would otherwise safe reboot?
â Brian Thomas
Aug 17 at 21:19
1
1
This is very much generic for most modern Linux systems so for instance answers wiert.me/2012/12/30/⦠After all these years wondering, I finally understand what's going on and why.
â Jeroen Wiert Pluimers
Sep 10 '16 at 15:17
This is very much generic for most modern Linux systems so for instance answers wiert.me/2012/12/30/⦠After all these years wondering, I finally understand what's going on and why.
â Jeroen Wiert Pluimers
Sep 10 '16 at 15:17
systemctl reboot
should be equivalent to systemctl start reboot.target --job-mode=replace-irreversible
. Using any other job mode is less robust. unix.stackexchange.com/questions/381739/â¦â sourcejedi
Aug 3 '17 at 14:47
systemctl reboot
should be equivalent to systemctl start reboot.target --job-mode=replace-irreversible
. Using any other job mode is less robust. unix.stackexchange.com/questions/381739/â¦â sourcejedi
Aug 3 '17 at 14:47
I read your entire reponse, and absorbed what I could. One question remains, the same one i came here for, is
systemctl reboot
the "safe" way to reboot, e.g. init 6
which is the way we would otherwise safe reboot?â Brian Thomas
Aug 17 at 21:19
I read your entire reponse, and absorbed what I could. One question remains, the same one i came here for, is
systemctl reboot
the "safe" way to reboot, e.g. init 6
which is the way we would otherwise safe reboot?â Brian Thomas
Aug 17 at 21:19
add a comment |Â
up vote
23
down vote
halt
instructs the hardware to stop all CPU functions, but leaves it in a powered-on state. This usually means someone has to reboot or shut the machine down manually by pressing the power button afterwards. The specific way to achieve this is architecture specific, but for instance the x86 instruction set provides theHLT
instructions which halts the central processing unit (CPU) until the next external interrupt is fired.poweroff
, likehalt
, stops the CPU but also sends an ACPI hardware signal which will instruct the system to commence with a complete and immediate shutdown. This is roughly equivalent to pressing the power button on a typical desktop computer.
Both halt
and poweroff
are usually symbolic links to the reboot
executable, which will usually invoke the shutdown
tool with the appropriate arguments (-h
, -P
or r
) depending on if halt
, poweroff
or reboot
was used to invoke the tool. However, When the --force
option is passed to reboot
, or when in runlevel 0 or 6, reboot
will invoke the reboot()
system call with an appropriate command code itself.
Thomas, thank you very much for explaining. I am interested to know what about doing a #init 0, there is not much differences right?
â Win.T
Apr 13 '15 at 9:41
@Win.T Switching to runlevel 0 using e.g./sbin/init 0
or/sbin/telinit 0
should be the same as halting the system, although the specific steps taken would depend on the init system in question, such as System-V init, upstart or systemd. If you're running RHEL, you would be using systemd.
â Thomas Nyman
Apr 13 '15 at 10:08
3
Note to self: every time someone complains about an arcane Win32 API call, show them reboot(2).
â immibis
Apr 13 '15 at 12:29
@immibis But reboot is purposely arcane. It requires the magic flags so that it is very difficult to do by accident.
â Kevin Cox
Apr 2 '16 at 15:12
3
@KevinCox That's the argument for requiring magic flags. It's not the argument for accepting 4 different values for magic2, nor for behaving differently inside a PID namespace, nor for lumping several barely-related operations (like setting reboot-on-Ctrl-Alt-Delete behaviour) into one function.
â immibis
Apr 2 '16 at 22:10
add a comment |Â
up vote
23
down vote
halt
instructs the hardware to stop all CPU functions, but leaves it in a powered-on state. This usually means someone has to reboot or shut the machine down manually by pressing the power button afterwards. The specific way to achieve this is architecture specific, but for instance the x86 instruction set provides theHLT
instructions which halts the central processing unit (CPU) until the next external interrupt is fired.poweroff
, likehalt
, stops the CPU but also sends an ACPI hardware signal which will instruct the system to commence with a complete and immediate shutdown. This is roughly equivalent to pressing the power button on a typical desktop computer.
Both halt
and poweroff
are usually symbolic links to the reboot
executable, which will usually invoke the shutdown
tool with the appropriate arguments (-h
, -P
or r
) depending on if halt
, poweroff
or reboot
was used to invoke the tool. However, When the --force
option is passed to reboot
, or when in runlevel 0 or 6, reboot
will invoke the reboot()
system call with an appropriate command code itself.
Thomas, thank you very much for explaining. I am interested to know what about doing a #init 0, there is not much differences right?
â Win.T
Apr 13 '15 at 9:41
@Win.T Switching to runlevel 0 using e.g./sbin/init 0
or/sbin/telinit 0
should be the same as halting the system, although the specific steps taken would depend on the init system in question, such as System-V init, upstart or systemd. If you're running RHEL, you would be using systemd.
â Thomas Nyman
Apr 13 '15 at 10:08
3
Note to self: every time someone complains about an arcane Win32 API call, show them reboot(2).
â immibis
Apr 13 '15 at 12:29
@immibis But reboot is purposely arcane. It requires the magic flags so that it is very difficult to do by accident.
â Kevin Cox
Apr 2 '16 at 15:12
3
@KevinCox That's the argument for requiring magic flags. It's not the argument for accepting 4 different values for magic2, nor for behaving differently inside a PID namespace, nor for lumping several barely-related operations (like setting reboot-on-Ctrl-Alt-Delete behaviour) into one function.
â immibis
Apr 2 '16 at 22:10
add a comment |Â
up vote
23
down vote
up vote
23
down vote
halt
instructs the hardware to stop all CPU functions, but leaves it in a powered-on state. This usually means someone has to reboot or shut the machine down manually by pressing the power button afterwards. The specific way to achieve this is architecture specific, but for instance the x86 instruction set provides theHLT
instructions which halts the central processing unit (CPU) until the next external interrupt is fired.poweroff
, likehalt
, stops the CPU but also sends an ACPI hardware signal which will instruct the system to commence with a complete and immediate shutdown. This is roughly equivalent to pressing the power button on a typical desktop computer.
Both halt
and poweroff
are usually symbolic links to the reboot
executable, which will usually invoke the shutdown
tool with the appropriate arguments (-h
, -P
or r
) depending on if halt
, poweroff
or reboot
was used to invoke the tool. However, When the --force
option is passed to reboot
, or when in runlevel 0 or 6, reboot
will invoke the reboot()
system call with an appropriate command code itself.
halt
instructs the hardware to stop all CPU functions, but leaves it in a powered-on state. This usually means someone has to reboot or shut the machine down manually by pressing the power button afterwards. The specific way to achieve this is architecture specific, but for instance the x86 instruction set provides theHLT
instructions which halts the central processing unit (CPU) until the next external interrupt is fired.poweroff
, likehalt
, stops the CPU but also sends an ACPI hardware signal which will instruct the system to commence with a complete and immediate shutdown. This is roughly equivalent to pressing the power button on a typical desktop computer.
Both halt
and poweroff
are usually symbolic links to the reboot
executable, which will usually invoke the shutdown
tool with the appropriate arguments (-h
, -P
or r
) depending on if halt
, poweroff
or reboot
was used to invoke the tool. However, When the --force
option is passed to reboot
, or when in runlevel 0 or 6, reboot
will invoke the reboot()
system call with an appropriate command code itself.
edited Apr 13 '15 at 9:17
answered Apr 13 '15 at 8:55
Thomas Nyman
19.2k74767
19.2k74767
Thomas, thank you very much for explaining. I am interested to know what about doing a #init 0, there is not much differences right?
â Win.T
Apr 13 '15 at 9:41
@Win.T Switching to runlevel 0 using e.g./sbin/init 0
or/sbin/telinit 0
should be the same as halting the system, although the specific steps taken would depend on the init system in question, such as System-V init, upstart or systemd. If you're running RHEL, you would be using systemd.
â Thomas Nyman
Apr 13 '15 at 10:08
3
Note to self: every time someone complains about an arcane Win32 API call, show them reboot(2).
â immibis
Apr 13 '15 at 12:29
@immibis But reboot is purposely arcane. It requires the magic flags so that it is very difficult to do by accident.
â Kevin Cox
Apr 2 '16 at 15:12
3
@KevinCox That's the argument for requiring magic flags. It's not the argument for accepting 4 different values for magic2, nor for behaving differently inside a PID namespace, nor for lumping several barely-related operations (like setting reboot-on-Ctrl-Alt-Delete behaviour) into one function.
â immibis
Apr 2 '16 at 22:10
add a comment |Â
Thomas, thank you very much for explaining. I am interested to know what about doing a #init 0, there is not much differences right?
â Win.T
Apr 13 '15 at 9:41
@Win.T Switching to runlevel 0 using e.g./sbin/init 0
or/sbin/telinit 0
should be the same as halting the system, although the specific steps taken would depend on the init system in question, such as System-V init, upstart or systemd. If you're running RHEL, you would be using systemd.
â Thomas Nyman
Apr 13 '15 at 10:08
3
Note to self: every time someone complains about an arcane Win32 API call, show them reboot(2).
â immibis
Apr 13 '15 at 12:29
@immibis But reboot is purposely arcane. It requires the magic flags so that it is very difficult to do by accident.
â Kevin Cox
Apr 2 '16 at 15:12
3
@KevinCox That's the argument for requiring magic flags. It's not the argument for accepting 4 different values for magic2, nor for behaving differently inside a PID namespace, nor for lumping several barely-related operations (like setting reboot-on-Ctrl-Alt-Delete behaviour) into one function.
â immibis
Apr 2 '16 at 22:10
Thomas, thank you very much for explaining. I am interested to know what about doing a #init 0, there is not much differences right?
â Win.T
Apr 13 '15 at 9:41
Thomas, thank you very much for explaining. I am interested to know what about doing a #init 0, there is not much differences right?
â Win.T
Apr 13 '15 at 9:41
@Win.T Switching to runlevel 0 using e.g.
/sbin/init 0
or /sbin/telinit 0
should be the same as halting the system, although the specific steps taken would depend on the init system in question, such as System-V init, upstart or systemd. If you're running RHEL, you would be using systemd.â Thomas Nyman
Apr 13 '15 at 10:08
@Win.T Switching to runlevel 0 using e.g.
/sbin/init 0
or /sbin/telinit 0
should be the same as halting the system, although the specific steps taken would depend on the init system in question, such as System-V init, upstart or systemd. If you're running RHEL, you would be using systemd.â Thomas Nyman
Apr 13 '15 at 10:08
3
3
Note to self: every time someone complains about an arcane Win32 API call, show them reboot(2).
â immibis
Apr 13 '15 at 12:29
Note to self: every time someone complains about an arcane Win32 API call, show them reboot(2).
â immibis
Apr 13 '15 at 12:29
@immibis But reboot is purposely arcane. It requires the magic flags so that it is very difficult to do by accident.
â Kevin Cox
Apr 2 '16 at 15:12
@immibis But reboot is purposely arcane. It requires the magic flags so that it is very difficult to do by accident.
â Kevin Cox
Apr 2 '16 at 15:12
3
3
@KevinCox That's the argument for requiring magic flags. It's not the argument for accepting 4 different values for magic2, nor for behaving differently inside a PID namespace, nor for lumping several barely-related operations (like setting reboot-on-Ctrl-Alt-Delete behaviour) into one function.
â immibis
Apr 2 '16 at 22:10
@KevinCox That's the argument for requiring magic flags. It's not the argument for accepting 4 different values for magic2, nor for behaving differently inside a PID namespace, nor for lumping several barely-related operations (like setting reboot-on-Ctrl-Alt-Delete behaviour) into one function.
â immibis
Apr 2 '16 at 22:10
add a comment |Â
up vote
3
down vote
halt
, poweroff
and shutdown -h
are completely equivalent. In fact, halt and poweroff do nothing but call shutdown -h
. From the halt/poweroff manpage:
If halt or reboot is called when the system is not in runlevel 0 or 6, in other words when it's running normally, shutdown will be invoked instead (with the -h or -r flag). For more info see the shutdown(8) manpage.
Shutdown then proceeds to shut down the system by switching to runlevel 0.
Halt and poweroff (and reboot) perform a dual role; when executed in the process of shutting down (i.e., in runlevel 0 or 6), they perform the low-level operations required to physically stop, power off, or reboot the machine, as described in another answer.
2
Which version of RHEL are you using? There normally is a difference between halt and poweroff (although for a while it used not to be the case in many distributions, but that was a bug).
â Bruno
Apr 13 '15 at 17:37
add a comment |Â
up vote
3
down vote
halt
, poweroff
and shutdown -h
are completely equivalent. In fact, halt and poweroff do nothing but call shutdown -h
. From the halt/poweroff manpage:
If halt or reboot is called when the system is not in runlevel 0 or 6, in other words when it's running normally, shutdown will be invoked instead (with the -h or -r flag). For more info see the shutdown(8) manpage.
Shutdown then proceeds to shut down the system by switching to runlevel 0.
Halt and poweroff (and reboot) perform a dual role; when executed in the process of shutting down (i.e., in runlevel 0 or 6), they perform the low-level operations required to physically stop, power off, or reboot the machine, as described in another answer.
2
Which version of RHEL are you using? There normally is a difference between halt and poweroff (although for a while it used not to be the case in many distributions, but that was a bug).
â Bruno
Apr 13 '15 at 17:37
add a comment |Â
up vote
3
down vote
up vote
3
down vote
halt
, poweroff
and shutdown -h
are completely equivalent. In fact, halt and poweroff do nothing but call shutdown -h
. From the halt/poweroff manpage:
If halt or reboot is called when the system is not in runlevel 0 or 6, in other words when it's running normally, shutdown will be invoked instead (with the -h or -r flag). For more info see the shutdown(8) manpage.
Shutdown then proceeds to shut down the system by switching to runlevel 0.
Halt and poweroff (and reboot) perform a dual role; when executed in the process of shutting down (i.e., in runlevel 0 or 6), they perform the low-level operations required to physically stop, power off, or reboot the machine, as described in another answer.
halt
, poweroff
and shutdown -h
are completely equivalent. In fact, halt and poweroff do nothing but call shutdown -h
. From the halt/poweroff manpage:
If halt or reboot is called when the system is not in runlevel 0 or 6, in other words when it's running normally, shutdown will be invoked instead (with the -h or -r flag). For more info see the shutdown(8) manpage.
Shutdown then proceeds to shut down the system by switching to runlevel 0.
Halt and poweroff (and reboot) perform a dual role; when executed in the process of shutting down (i.e., in runlevel 0 or 6), they perform the low-level operations required to physically stop, power off, or reboot the machine, as described in another answer.
answered Apr 13 '15 at 12:16
marcelm
84138
84138
2
Which version of RHEL are you using? There normally is a difference between halt and poweroff (although for a while it used not to be the case in many distributions, but that was a bug).
â Bruno
Apr 13 '15 at 17:37
add a comment |Â
2
Which version of RHEL are you using? There normally is a difference between halt and poweroff (although for a while it used not to be the case in many distributions, but that was a bug).
â Bruno
Apr 13 '15 at 17:37
2
2
Which version of RHEL are you using? There normally is a difference between halt and poweroff (although for a while it used not to be the case in many distributions, but that was a bug).
â Bruno
Apr 13 '15 at 17:37
Which version of RHEL are you using? There normally is a difference between halt and poweroff (although for a while it used not to be the case in many distributions, but that was a bug).
â Bruno
Apr 13 '15 at 17:37
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f195898%2fwhat-is-the-difference-between-these-commands-for-bringing-down-a-linux-server%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Related askubuntu.com/q/578144/216503
â heemayl
Apr 13 '15 at 13:36
This is some of the things that differ significantly for e.g. Solaris and FreeBSD. (There they usually (almost) immediately halt / shutdown the server, without changing runlevels to shut down stuff first)
â Gert van den Berg
Jan 4 '17 at 12:52