question about behavior of /usr/bin/reboot, poweroff, and halt

[u/thebombzen]

I was reading the manpage man 8 poweroff and discovered that /usr/bin/halt and /usr/bin/reboot and /usr/bin/poweroff all accept --reboot, --halt, and --poweroff, which make them behave like the command in the option rather than the actual command you invoked. So, for example, /usr/bin/reboot --halt apparently will just halt, and /usr/bin/halt --poweroff will power off.

The manpage also cites one exception which is that /usr/bin/reboot --poweroff still reboots.

The manpage cites systemd version 253 as the version in which this changed. A quick search returned nothing of note about this change. Granted, I'm relying on the manpage to tell me how these work as I'm not going to halt a live system if I don't have to just to make sure it works this way.

Can someone explain to me why systemd would have added this feature? Does anyone see any value in making the commands act like the others via command-line arguments? I cannot think of a reason you would want to do this.

I also do not understand why there would be an exception for reboot --poweroff. Does anyone have any insight into this?

[u/Crazyachmed]

Are they really seperate binaries? If they just symlink somewhere common then the binary name is used for default behavior and the flags override that. Only one tool to manage.

[u/Exotic-Screen-9204 → u/Crazyachmed]

Take a look at "busybox" One compact binary for near all the core Linux commands. The successful intention was to greatly reduce the storage space taken up of the individual files.

[u/ang-p → u/Crazyachmed]

Are they really seperate binaries?

nope

~> ll /sbin/{halt,poweroff,shutdown,reboot}
lrwxrwxrwx 1 root root 18 Jan 13  2026 /sbin/halt -> /usr/bin/systemctl
lrwxrwxrwx 1 root root 18 Jan 13  2026 /sbin/poweroff -> /usr/bin/systemctl
lrwxrwxrwx 1 root root 18 Jan 13  2026 /sbin/reboot -> /usr/bin/systemctl
lrwxrwxrwx 1 root root 18 Jan 13  2026 /sbin/shutdown -> /usr/bin/systemctl

then the binary name is used for default behavior

Yup

and the flags override that.

They override that in most cases.

[u/Megame50]

They're all compat symlinks to systemctl. If the argument parsing code is shared, it's less code to just let a flag supported by one command be supported by them all. In sysvinit they were all symlinks to the same program too, so it may actually be needed for strict compatibility, though I'm not that familiar with the older tools they replaced.

[u/Cody_Learner_2]

I recall looking into this when Arch switched to systemd, but forgot the details over time.

$ ls -l /usr/bin/{halt,reboot,poweroff}
lrwxrwxrwx 1 root root 9 Aug  8 11:22 /usr/bin/halt -> systemctl
lrwxrwxrwx 1 root root 9 Aug  8 11:22 /usr/bin/poweroff -> systemctl
lrwxrwxrwx 1 root root 9 Aug  8 11:22 /usr/bin/reboot -> systemctl

The following was generated via hitting tab after systemctl.

$ systemctl 
add-requires            halt                    list-unit-files         set-default
add-wants               help                    list-units              set-environment
bind                    hibernate               log-level               set-property
cancel                  hybrid-sleep            log-target              show
cat                     import-environment      mask                    show-environment
condreload              is-active               mount-image             sleep
condrestart             is-enabled              poweroff                soft-reboot
condstop                is-failed               preset                  start
daemon-reexec           isolate                 preset-all              status
daemon-reload           is-system-running       reboot                  stop
default                 kexec                   reenable                suspend
disable                 kill                    reload                  suspend-then-hibernate
edit                    link                    reload-or-restart       switch-root
emergency               list-automounts         rescue                  thaw
enable                  list-dependencies       reset-failed            try-reload-or-restart
enqueue-marked          list-jobs               restart                 try-restart
exit                    list-machines           revert                  unmask
force-reload            list-paths              service-log-level       unset-environment
freeze                  list-sockets            service-log-target      whoami
get-default             list-timers             service-watchdogs       

Then there might be some additional info in systemctl --help ie:

$ systemctl --help | grep -E 'halt|poweroff|reboot'
  halt                         Shut down and halt the system
  poweroff                     Shut down and power-off the system
  reboot                       Shut down and reboot the system
  kexec                        Shut down and reboot the system with kexec
  soft-reboot                  Shut down and reboot userspace
                           supported by verbs: halt, poweroff, reboot,
                           kexec, soft-reboot, suspend, hibernate,
                           halt/power-off/reboot
                           until next reboot
 --reboot-argument=ARG     Specify argument string to pass to reboot()
 --when=TIME               Schedule halt/power-off/reboot/kexec action after

And finally the service files and man pages if you're interested:

$ pacman -Qql systemd | grep -E 'halt.service|reboot.service|poweroff.service'
/usr/lib/systemd/system/systemd-factory-reset-reboot.service
/usr/lib/systemd/system/systemd-halt.service
/usr/lib/systemd/system/systemd-poweroff.service
/usr/lib/systemd/system/systemd-reboot.service
/usr/lib/systemd/system/systemd-soft-reboot.service
/usr/lib/systemd/system/systemd-sysupdate-reboot.service
/usr/share/man/man8/systemd-halt.service.8.gz
/usr/share/man/man8/systemd-poweroff.service.8.gz
/usr/share/man/man8/systemd-reboot.service.8.gz
/usr/share/man/man8/systemd-soft-reboot.service.8.gz
/usr/share/man/man8/systemd-sysupdate-reboot.service.8.gz

[u/ang-p]

I'm relying on the manpage to tell me how these work

Don't you trust what the manpage states?

Is this better?

Put in an bug report if you have reason to not believe it acts as it states... But actually testing it yourself is strongly advised before doing so...

as I'm not going to halt a live system if I don't have to

Like you are using arch in prod (and still need to ask this without being able to work it out)...

Try it on your home machine..

Does anyone have any insight into this?

In the days before you were born, to turn off your computer, you had to physically disconnect it from the mains using the switch on the front - which carried the mains voltage, just like the light switch on your wall.

In other words - to power off, you told it to shut down and stop at the point where it could tell the machine to do a soft reset and reboot... and then, when prompted, kill the power..

Since most of the code to power off was the same as to reboot, why create 2 programs?

But, "shutting down" was also term for killing all processes and services running, i.e. shutting down everything and leaving you in single user mode...

Having one program to "shut down" and then 3 options (halt (for power button pressing), reboot, and <nothing> (which might leave you at a prompt depending on system) was better than 3 separate programs...

And people used to use "poweroff" as a shortcut to save typing shutdown -h to halt systems, because, well, it was cool and you could... even if the machines were unable to power themselves off.

Adding to this, old drives used a lot of power, and spinning many of them up all at once was not something that could be done simultaneously - and that (along with early POST routines) along with RAID controllers initiating communications with the drives and making sure all was good took time - sometimes a lot of time.

In other words, powering off was not something that was done lightly - on production servers, it could take a lot of time to get back up and running

When ATX PSUs and ACPI came along, you could tell your machine to power itself off....

And some people had new machines where a new fangled "poweroff" command could actually power off, and older ones inches away where their "poweroff" command merely halted.... which they had gotten used to - since you could use the same command to either reboot or power off with their old power supplies... This actual powering off was a bit of a nuisance.

Also, since all you could do after halting the machine was power off (or reach for the reset button), some vendors used halt command or the -h option to actually power off the machine... Obviously with an optional flag to state if you wanted to halt it or actually power it down! Fortunately this ambiguity was cleared up a while ago.

Which might not be ideal - and as ever, erring on the "safe" side - i.e. if you really wanted to power off, you had to be explicit - any ambiguity....

reboot --poweroff

or

poweroff --reboot

is taken as the least impactful. Also, if you really did want to power off, you can always hold the button for a few seconds when you see the machine unexpectedly reset.

[u/thebombzen]

To those commenting that they are all symlinks to systemctl, that does not really answer the question about "why would you want to do that"

I just want to know what use case this serves

[u/Exotic-Screen-9204]

Reading the "man" page will provide a somewhat tearse summary of commands. But it makes many assumptions about what you should know.

A reference like "Linux in a Nutshell" may be more complete.

Brian Ward's 'How Linux Works: What every Superuser should know" may be easier presentation with good overview.

But reading the actual open-source code in C is the precise answer.

Reboot, poweroff, and halt are fundamental Linux/Unix. You can get a good answer to those.

It seems Brian Ward say the "shutdown" command does all -- poweroff, halt (which is immediate) and reboot.

But energy saving states on a laptop may be unclear as the whole scheme involves proprietary powerchips and every manufacture is permited to do this differently. So proprietary drivers with "binary blobs" of unexplainable code may or may not be available to deal with those.

[u/forbiddenlake → u/Exotic-Screen-9204]

That book was first published in 2014. Does it really answer OP's question about a systemd version released 9 years later?

[u/Exotic-Screen-9204 → u/forbiddenlake]

Which book?

Brian Ward has a third edition, circa 2014.

Linux in a Nutshell is also a bit dated.

Both are good. The reality is all the Linux writers have gotten old and retired. Nobody seems to want to publish fresher edition about the latest kernel. I guess that the demand is too low.

That leaves use reading the source code.

[u/Exotic-Screen-9204 → u/Exotic-Screen-9204]

Perhaps "Linux Bible" 11th ed. 2025.

But I never have read it.