How to Shut Down or Reboot Linux from the Terminal

A clean shutdown stops services in order, flushes data to disk and unmounts filesystems. Pulling the power (or a hard reset in a VM console) skips all of that, and databases or journals have to recover on the next boot. On a systemd-based distro, which is every mainstream one today, all shutdown commands end up doing the same clean sequence. They differ only in syntax and timing.

Shut down now

sudo shutdown now
sudo poweroff
sudo systemctl poweroff

All three power the machine off immediately. On systemd, shutdown, poweroff, reboot and halt are compatibility wrappers around systemctl. sudo shutdown -h now from older guides still works: on systemd, -h means power off, same as -P.

Note that shutdown with no time argument does not shut down immediately. It schedules a power-off in one minute (+1).

Reboot

sudo reboot
sudo shutdown -r now
sudo systemctl reboot

Halt is not power off

sudo halt (or shutdown -H) stops the system but does not cut power. On a physical server you are left with a machine that is on but doing nothing. Use poweroff unless you specifically want that.

Scheduled shutdowns

sudo shutdown +15 "Maintenance: rebooting in 15 minutes"   # in 15 minutes
sudo shutdown -r 23:30 "Kernel update reboot"              # at 23:30 local time
shutdown --show                                            # what is scheduled
sudo shutdown -c                                           # cancel it

The message is broadcast to every logged-in terminal. Five minutes before the scheduled time, systemd creates /run/nologin, which blocks new non-root logins. shutdown --show needs systemd 250 or newer. On older systems, check /run/systemd/shutdown/scheduled.

For recurring shutdowns, use a cron entry or a systemd timer. A root crontab line (sudo crontab -e):

0 2 * * 0 /usr/sbin/shutdown -r now

That reboots every Sunday at 02:00. Use the full path, because cron runs with a minimal PATH.

For a one-off at an arbitrary time, shutdown with a clock time is simpler than at and can be cancelled with -c.

Before shutting down a shared server

Check who else is on it and whether something is blocking shutdown:

who                       # logged-in users
w                         # same, plus what they are running
systemd-inhibit --list    # processes that asked to delay or block shutdown

Inhibitors are things like a package manager in the middle of an upgrade or a desktop session. If systemctl poweroff refuses because of an inhibitor, find out what it is before overriding it. Interrupting a package upgrade halfway can leave the system unbootable.

Remote servers over SSH

ssh user@203.0.113.10 'sudo shutdown -r now'

The SSH session drops as soon as networking goes down. That is expected. If you power off a remote machine, make sure you have a way to start it again: a cloud console, IPMI or iDRAC, or someone on site. A powered-off bare-metal server in a remote data center does not come back on its own.

On cloud VMs, shutting down from inside the guest stops the instance. On AWS EC2, check the instance's shutdown behavior attribute: if it is set to terminate, an OS-level poweroff deletes the instance. For planned stops, using the provider's API (aws ec2 stop-instances, gcloud compute instances stop) is clearer.

Running something at shutdown

To run a cleanup script on every shutdown, use a systemd unit with ExecStop, not a hack in rc scripts:

# /etc/systemd/system/my-cleanup.service
[Unit]
Description=Cleanup on shutdown
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecStop=/usr/local/bin/my-cleanup.sh

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now my-cleanup.service

The unit counts as "running" after boot. On shutdown, systemd stops it and runs ExecStop. Units stop in reverse order of startup, so the After=network-online.target line means the network is still up while the script runs.

When shutdown hangs

A message like "A stop job is running for ..." means a service is not stopping. systemd waits for the unit's stop timeout (90 seconds by default, longer for some units) and then kills it. Usually waiting is the right answer.

After the next boot, find out which service it was:

journalctl -b -1 -e      # end of the previous boot's log

If a machine is truly stuck and you have console access, the Magic SysRq keys are a better last resort than the power button, because they sync and remount disks first. From a shell that still responds:

echo 1 | sudo tee /proc/sys/kernel/sysrq
echo s | sudo tee /proc/sysrq-trigger    # sync filesystems
echo u | sudo tee /proc/sysrq-trigger    # remount read-only
echo b | sudo tee /proc/sysrq-trigger    # reboot immediately (o = power off)

b and o do not stop services. They are only for a system that cannot shut down normally.

Quick reference

sudo poweroff                     # power off now
sudo reboot                       # reboot now
sudo shutdown now                 # power off now
sudo shutdown +10 "message"       # power off in 10 minutes
sudo shutdown -r 23:30            # reboot at 23:30
shutdown --show                   # show scheduled shutdown
sudo shutdown -c                  # cancel scheduled shutdown
sudo halt                         # stop the system without powering off
systemd-inhibit --list            # what is blocking shutdown
journalctl -b -1 -e               # why the last shutdown was slow