Power Off, Reboot or Halt with systemd

poweroff, reboot and halt are the three commands standing between you and an actually-off machine, and mixing them up matters more than people expect. The examples match the installed systemd-sysv 255.4-1ubuntu8.17 interface, where all three are compatibility commands implemented through systemd. Allow about ten minutes to read and check the syntax.

You need a shell account with permission to manage the machine. The final power operation normally requires elevated privileges and will end your session, so save work and confirm the target host before running it.

1. Check the Command Without Changing the Machine

First confirm which command is installed and read its local help. These are ordinary, read-only checks and need no sudo:

$ command -v poweroff
/usr/sbin/poweroff
$ readlink -f "$(command -v poweroff)"
/usr/bin/systemctl
$ dpkg-query -W systemd-sysv
systemd-sysv 255.4-1ubuntu8.17
$ poweroff --help
poweroff [OPTIONS...]

Power off the system.

The exact help text can vary between systemd releases. On this installation it identifies the command as a compatibility interface and lists the operation selectors, force mode, wtmp handling and wall-message control. The matching halt(8), poweroff(8) and reboot(8) manuals describe the same option set.

2. Choose the Operation You Actually Mean

Use the command whose name says what should happen:

That last distinction is easy to miss. Older SysV systems often treated halt as another spelling of power-off. systemd documents the more precise behaviour: use poweroff when the machine must actually turn off.

Each command also accepts an explicit operation selector: halt --reboot requests a reboot, while poweroff --halt requests a halt. Useful in generated scripts where the command name is fixed by another interface; for interactive work, the direct command name is clearer.

3. Perform a Normal, Graceful Operation

For a graceful power-off:

$ hostname
server.example.test
$ sudo poweroff

For a restart, substitute reboot:

$ sudo reboot

For a halt that leaves power on:

$ sudo halt

By default these commands hand the request to the init system. The normal path syncs storage, records the shutdown in wtmp and sends the wall message unless you explicitly pick different behaviour. You may see a password prompt, a broadcast message, or no further shell prompt at all because the operation has already begun.

$ uptime
 10:42:18 up 1 min,  1 user,  load average: 0.03, 0.02, 0.00

The uptime and load values above are examples, not fixed output. For a power-off, the useful verification is that the host no longer accepts connections. If you halted it intentionally, use the console or your remote management system to confirm power remains available.

4. Understand the Options Before Using Them

The ordinary command is usually the safest choice. These options change its side effects:

• -w or --wtmp-only writes a shutdown entry but does not halt, reboot or power off. It still changes the login accounting file, so use it only when that record is the actual purpose of the test.
• -d or --no-wtmp suppresses the shutdown entry. This makes operational auditing less useful and should not be added just to hide noise.
• --no-wall suppresses the message to logged-in users. Use it only when you have another way to warn people of the interruption.
• -p or --poweroff selects power-off when invoked as halt or poweroff. Ignored when invoked as reboot.
• --halt and --reboot select those operations regardless of the command name used to invoke them.

Use poweroff --help on the target host to check an option. The manual also documents -n or --no-sync, which skips syncing storage. That is a data-integrity risk, not a performance tweak.

5. Treat Force Mode as an Emergency Measure

Before considering force mode, investigate the graceful operation from a separate console or management channel: look for a blocked service, an unresponsive mount or a storage problem. If you must use force mode to recover a machine, accept that unsaved application data can be lost and filesystem checks may be needed at the next boot.

6. Diagnose the Common Mistakes

If a normal command fails immediately, check the exit status and the service manager state without repeating the destructive request:

$ sudo poweroff
$ printf 'poweroff status: %s\n' "$?"
poweroff status: 1
$ systemctl is-system-running
degraded

The exact status and diagnostic text depend on the failure. A non-zero status means the request failed; it does not mean the machine is safe to keep using without checking why. Review the terminal message and the relevant journal entries with your normal systemd diagnostics.

If you meant to restart but used halt, remember that halt leaves power on. If a script uses a generic command name, make the intended operation explicit with the correct command or selector, and test it in a disposable environment first. Never test a shutdown script on a production host merely to discover which branch it takes.