Updated: 17 October 2026 · Applies to: Linux with systemd (tested with systemd 257 on AlmaLinux 10.2; the same commands on RHEL and Rocky Linux 9 and 10, Debian 13, Ubuntu 24.04 and 26.04); sudo 1.9.17p2, sudo-rs 0.2.13, molly-guard 0.8.5

To shut down a Linux server, run sudo shutdown -h now (or sudo poweroff); to restart it, run sudo shutdown -r now (or sudo reboot). The commands are the same on Ubuntu, Debian, Red Hat Enterprise Linux, AlmaLinux and Rocky Linux. To stop other people from running them, give them sudo rights only for the commands they need. To block shutdowns for everyone, including root, mask the systemd shutdown targets. On Debian and Ubuntu, molly-guard protects against shutting down the wrong server over SSH. The old trick of denying !SHUTDOWN in sudoers is easy to get around, as shown below.

Shut down or restart a Linux server

  • sudo shutdown -h now, sudo poweroff or sudo systemctl poweroff: power off now.
  • sudo shutdown -r now, sudo reboot or sudo systemctl reboot: restart now.
  • sudo shutdown -h +10 "Maintenance": power off in 10 minutes and warn logged-in users. sudo shutdown -r 23:30 restarts at 23:30 server time.
  • shutdown --show shows a pending shutdown; sudo shutdown -c cancels it.

Output on AlmaLinux 10.2 (logged in as root):

# shutdown -h +10 "Maintenance: the server goes down in 10 minutes"
Shutdown scheduled for Mon 2026-10-12 03:11:23 UTC, use 'shutdown -c' to cancel.
# shutdown -c
# shutdown --show
No scheduled shutdown.

On systemd systems, shutdown, reboot, halt and poweroff are links to systemctl (ls -l /usr/sbin/shutdown shows /usr/sbin/shutdown -> ../bin/systemctl), so all of them do the same thing. The differences between halt and power off: shutdown, poweroff, halt and reboot commands. Restarting over SSH or PuTTY: Linux reboot command. On FreeBSD and other BSD systems the options differ: according to the FreeBSD manual, shutdown -p now powers off and -h only halts.

Shut down only a network interface

To take one interface down without stopping the server, use sudo ip link set dev eth1 down and bring it back with sudo ip link set dev eth1 up (ip -br link then shows DOWN or UP). With NetworkManager, sudo nmcli device disconnect eth1 keeps the device down until you connect it again, according to the nmcli manual. Never do this to the interface your SSH session uses: you lose the connection and need the console (access your VPS via VNC).

Who can shut down a server

Root, users with sudo rights and, on a desktop, the person at the screen. A normal user without polkit installed is refused (tested on AlmaLinux 10.2):

$ shutdown -h now
Call to PowerOff failed: Access denied

With polkit installed, systemd's policy for org.freedesktop.login1.power-off lets the user at the active local session (the desktop) power off without a password (allow_active is yes) and asks for an administrator's password in any other session, such as SSH (auth_admin_keep). So on a server, controlling shutdowns means controlling sudo and the root password.

Method 1: give sudo only the commands a user needs

Instead of full sudo, list the allowed commands. Create a drop-in file with sudo visudo -f /etc/sudoers.d/webadmin:

deploy ALL=(root) /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx

The user can now restart nginx, and nothing else:

$ sudo systemctl poweroff
Sorry, user deploy is not allowed to execute '/usr/bin/systemctl poweroff' as root on vps.

sudo-rs, the default sudo on Ubuntu 26.04, refused it with sudo: I'm sorry deploy. I'm afraid I can't do that and allowed the nginx restart. sudo-rs rejects wildcards in command arguments, so list each command in full. More on sudo rules: sudoers NOPASSWD and add a user to sudo on Debian. If a typing error breaks the file, see fix a broken sudoers file.

Method 2 (weak): deny the shutdown commands in sudoers

The common advice is to take the commands away from a user who otherwise has full sudo:

Cmnd_Alias SHUTDOWN = /sbin/shutdown, /sbin/reboot, /sbin/halt, /sbin/poweroff
deploy ALL=(ALL:ALL) ALL, !SHUTDOWN

The commands themselves are then refused. Classic sudo said Sorry, user deploy is not allowed to execute '/usr/sbin/shutdown -h now' as root on vps. and sudo-rs said sudo: I'm sorry deploy. I'm afraid I can't do that. But in our tests on Ubuntu 26.04 and AlmaLinux 10.2, the same user could still run sudo systemctl poweroff and open a root shell with sudo bash. The sudoers manual says it plainly: "It is generally not effective to subtract commands from ALL using the ! operator." Treat this rule as a reminder, not as protection.

Method 3: block shutdown and reboot for everyone

During critical work (a long backup, a migration) you can make the normal shutdown commands fail, even for root:

  1. Mask the targets:
    # systemctl mask poweroff.target reboot.target halt.target
    Created symlink '/etc/systemd/system/poweroff.target' → '/dev/null'.
    Created symlink '/etc/systemd/system/reboot.target' → '/dev/null'.
    Created symlink '/etc/systemd/system/halt.target' → '/dev/null'.
  2. Test it. shutdown -h now, reboot and systemctl poweroff all failed with Call to PowerOff failed: Access denied (or Call to Reboot failed), and the journal of systemd-logind recorded Unit poweroff.target is masked, refusing operation. A scheduled shutdown was accepted but failed when its time came: Scheduled shutdown to poweroff.target failed: Permission denied.
  3. Undo it when you are done, for example before a kernel update that needs a reboot:
    sudo systemctl unmask poweroff.target reboot.target halt.target

Limits: systemctl poweroff --force skips the targets and powered off our test system despite the mask. A VPS can also still be stopped from its control panel. To block the Ctrl+Alt+Del key on the console, see disable Ctrl+Alt+Del reboots (on AlmaLinux, Rocky Linux and RHEL that needs systemctl mask --force ctrl-alt-del.target).

Method 4: molly-guard against mistakes over SSH (Debian, Ubuntu)

Many unwanted shutdowns are simply typed into the wrong SSH window. molly-guard asks for the host name first:

sudo apt install molly-guard

In an SSH session, a wrong answer stops the command (tested as root on Ubuntu 26.04 with a simulated SSH session, hostname vps):

# shutdown -h now
W: molly-guard: SSH session detected!
Please type in hostname of the machine to shutdown: wronghost
Good thing I asked; I won't shutdown vps ...
W: aborting shutdown due to 30-query-hostname exiting with code 1.

It replaces shutdown, reboot, halt and poweroff, but not systemctl poweroff or systemctl reboot. The package is in Debian 13 (0.8.5), Ubuntu 24.04 (0.8.3) and Ubuntu 26.04 (0.8.5).

Do not remove the execute permission from systemctl

Older guides suggest chmod o-x /bin/systemctl. In our test, normal users then could not even run systemctl status (/usr/bin/systemctl: Permission denied), and rpm -V systemd flagged the file as modified (.M....... /usr/bin/systemctl). It also adds nothing: normal users without sudo cannot shut down a server anyway.

To log who shut a server down, see audit rules to log who ran reboot or shutdown; to warn users first, see show a custom message before a shutdown.

Official documentation: systemctl, shutdown and sudoers.

Related services

KVM VPS hosting

NVMe SSD and full root access, with Free Basic Managed Support.

Unmanaged dedicated servers

full root access and free IPMI KVM, with Free Basic Managed Support.

Managed dedicated servers

our engineers look after the server for you, from $135 a month.

Was this answer helpful?

Still stuck? Open a ticket