How to Reboot a Linux Server Safely: Every Command

Use sudo systemctl reboot. It asks systemd to stop every service cleanly, unmount the filesystems and restart. On any distribution released in the last decade, sudo reboot and sudo shutdown -r now are aliases for the same thing, so pick whichever you remember.

# The modern form, and the one to prefer
sudo systemctl reboot

# Short form: identical behaviour on systemd distributions
sudo reboot

# The traditional form, still supported everywhere
sudo shutdown -r now

Use shutdown with a time. It broadcasts a warning to anyone logged in, blocks new logins in the final five minutes, and can be cancelled right up until it fires. That last part is the reason to prefer it over a cron job.

# In 10 minutes, with a message to logged-in users
sudo shutdown -r +10 'Kernel update, back in about 2 minutes'

# At a specific time, 24-hour clock, server local time
sudo shutdown -r 02:30 'Scheduled maintenance window'

# Change your mind
sudo shutdown -c

# Check whether one is already scheduled
systemctl list-jobs | grep -i shutdown

Usually not. Most updates take effect the moment the service restarts, and restarting one service beats restarting the whole machine. A reboot is genuinely required for a kernel update, a glibc update, or a firmware or hypervisor change. Debian and Ubuntu tell you directly.

# Debian / Ubuntu: this file exists only if a reboot is needed
ls -l /var/run/reboot-required 2>/dev/null && cat /var/run/reboot-required.pkgs

# RHEL family: needs-restarting is in the dnf-utils package
sudo needs-restarting -r

# Which services are running against deleted libraries?
sudo needs-restarting -s        # RHEL family
sudo checkrestart               # Debian / Ubuntu, from debian-goodies

If a service is just holding an old library, restart that service instead. It costs seconds rather than minutes and nothing else on the machine notices.

sudo systemctl restart nginx
sudo systemctl restart php8.3-fpm
sudo systemctl restart mariadb

# Reload rather than restart where the service supports it:
# rereads config with no dropped connections
sudo systemctl reload nginx

The risk in a reboot is almost never the reboot itself. It is discovering, two minutes later, that something was running only because someone started it by hand months ago and never enabled it at boot. Run through these five checks first.

1. 1Confirm every service you depend on is enabled at boot. systemctl list-unit-files --state=enabled lists what will actually start. If nginx, php-fpm or your database is missing from that list, fix it before you restart, not after.
2. 2Check nothing long-running is in flight. A backup, a database import or a large rsync will be killed mid-write. ps aux | grep -E 'rsync|mysqldump|tar' takes two seconds.
3. 3Take a backup you have tested. A reboot exposes problems that were already there, such as a filesystem that will not mount cleanly. Have a way back. Our backup strategy guide covers what makes a backup usable.
4. 4Know how you get in if SSH does not come back. Console access through your provider's panel, or a second route in. Without it, a failed boot means a support ticket and an unknown wait.
5. 5Pick a genuinely quiet window. Check your traffic, not your assumptions about it. Overnight in your timezone is peak somewhere else if you have international visitors.

# Will everything come back on its own?
systemctl list-unit-files --state=enabled | grep -E 'nginx|apache|php|maria|mysql|postgres'

# Anything long-running I would be killing?
ps aux | grep -E '[r]sync|[m]ysqldump|[t]ar|[a]pt|[d]nf'

# Any failed units already? Fix these first, a reboot will not help
systemctl --failed

# How long has it been up, and what is the load?
uptime

Do not stop at a successful SSH login. The machine being up and the site being up are different claims. Check the boot itself, then the services, then the site.

# Confirm it really did restart, and when
uptime -s
who -b

# Did anything fail to start?
systemctl --failed

# How long did the boot take, and what was slow?
systemd-analyze
systemd-analyze blame | head -10

# Read this boot's log for errors only
sudo journalctl -b -p err

# Finally, test the site from outside the server
curl -s -o /dev/null -w '%{http_code} in %{time_total}s\n' https://example.com/

If something did fail to start, the log will say why. Understanding Linux system logs covers reading journalctl and finding the service-specific logs underneath it.

Give it longer than you think. A machine that fsck's a large filesystem, or waits on a network mount, can take several minutes with no external sign of life. If it is still silent after ten, work through this in order.

1. 1Ping it. If it answers ping but refuses SSH, the machine booted and the problem is sshd or a firewall rule, which is a much better position to be in.
2. 2Open the provider's console. Serial or VNC console shows you the boot messages directly. That is where a failed mount or a kernel panic will be visible.
3. 3Look for a filesystem check. A large disk being verified can take a long time and will tell you so on the console. The right response is to wait.
4. 4Boot the previous kernel. If the reboot followed a kernel update, pick the older entry in the GRUB menu from the console. If it boots, you have your answer.
5. 5Boot into rescue mode to repair a bad fstab entry or a broken mount, which is the most common cause of a machine that hangs during boot.