Short answer: sudo reboot restarts the machine right away, sudo shutdown -h now (or sudo poweroff) powers it off, and sudo shutdown -r now is the explicit way to reboot through the shutdown command rather than the standalone reboot binary. All of these need root — run them with sudo as any other user. Every command and flag on this page was checked against the systemd-based shutdown(8) and reboot(8) man pages on Debian 12, which is what current Debian and Ubuntu both run.
sudo reboot # restart now
sudo shutdown -h now # halt and power off now
sudo poweroff # the same, directlyThe shutdown command: halt, power off, or reboot, with a delay
shutdown is the one command that does all three, and the only one of the group that takes a time argument and a warning message to logged-in users:
shutdown [OPTIONS] [TIME] [WALL MESSAGE]| Command | What it does |
|---|---|
sudo shutdown now | Power off immediately — poweroff is the default action |
sudo shutdown -r now | Reboot immediately |
sudo shutdown -h now | Halt/power off immediately, written out explicitly |
sudo shutdown +10 | Power off in 10 minutes |
sudo shutdown -r +5 "rebooting for updates" | Reboot in 5 minutes, with a message sent to every logged-in session |
sudo shutdown 23:00 | Power off at 23:00 today (24-hour clock) |
sudo shutdown -c | Cancel a pending shutdown scheduled with a time argument |
sudo shutdown --show | Show whether a shutdown is currently scheduled, and when |
now is shorthand for +0. Leaving the time argument out entirely defaults to +1 — one minute from now, not immediate — which is the usual explanation when sudo shutdown on its own seems to do nothing for a moment. A time argument also triggers an /run/nologin file five minutes before the machine goes down, which blocks new logins in that window; shutdown -c only works while a scheduled time is still pending — once the countdown reaches zero there is nothing left to cancel.
reboot, halt and poweroff: the direct commands
On a systemd system these three are effectively the same program under different names, each defaulting to the action its name suggests. reboot always reboots regardless of which of the three you typed; poweroff and halt differ in one detail: halt stops the kernel but can leave the hardware powered on, while poweroff actually cuts the power. halt -p (or running it as poweroff) powers off; poweroff itself ignores -p since it already means that.
sudo reboot
sudo poweroff
sudo halt| Flag | Effect |
|---|---|
-f, --force | Immediate action without asking the init system first; filesystems are usually not unmounted cleanly — a last resort, not the default move |
-n, --no-sync | Skip the disk sync before acting |
--no-wall | Don't send the wall message to other logged-in sessions |
systemctl reboot / poweroff / halt
systemctl offers the same three actions, and they are the ones that actually run under the hood even when you type the shorter commands above — reboot, poweroff and shutdown -r now all end up asking systemd to do the same job.
sudo systemctl reboot
sudo systemctl poweroff
sudo systemctl haltAll three are asynchronous: the command returns as soon as the action is queued, before the machine has actually finished going down — on an interactive SSH session this rarely matters, since the connection drops anyway, but it matters if a script checks the exit code expecting it to mean “the machine is now off.” --force skips the orderly shutdown of running services first; passed twice, it skips the service manager entirely and talks to the kernel directly — meant for when systemd itself has crashed, not routine use.
Which command should I actually use?
- Need it right now, nothing fancy:
sudo rebootorsudo poweroff. Shortest to type, same result. - Need a delay, or to warn other logged-in users first:
shutdown— it is the only one of the group built for that. - Writing a script or an automation tool:
systemctl reboot/systemctl poweroffare the most explicit about exactly what they ask systemd to do, and read clearly in a playbook or a runbook months later.
After a reboot you didn’t expect
If the server came back up on its own rather than because you asked it to, VPS keeps rebooting covers the actual causes — an OOM kill, a kernel panic, a watchdog, a scheduled shutdown left running by a script or a forgotten cron job. last reboot (reading /var/log/wtmp) and journalctl --list-boots are the first two commands to run to see exactly when each past boot happened, before chasing the cause any further.
Rebooting as part of a bigger job
A planned reboot is also a normal, expected step partway through an in-place major version upgrade — see upgrading Debian 12 to 13 for exactly where in that sequence a reboot belongs and why skipping it there causes real problems, unlike an ad-hoc reboot on a server that is otherwise idle.
Frequently asked
What is the difference between reboot and shutdown -r now?
On a systemd system they do the same thing in practice — both ask systemd to reboot. shutdown additionally accepts a delay and a wall message to logged-in users (shutdown -r +10 "rebooting for updates"), which plain reboot does not take at all.
How do I cancel a scheduled shutdown?
sudo shutdown -c, but only while the countdown from an earlier shutdown +TIME is still pending. Once it reaches zero and the machine starts going down, there is nothing left to cancel.
How do I delay a reboot by a few minutes?
sudo shutdown -r +10 reboots in 10 minutes; sudo shutdown -r 23:00 reboots at 23:00 today on the 24-hour clock. Leaving the time argument out entirely on plain shutdown defaults to +1 (one minute), not immediately.
Do I need root to reboot a Linux server?
Yes — reboot, shutdown, poweroff, halt and systemctl reboot/poweroff all require root. Run them with sudo as any other user.