Tutoriel Linux

Restarting Linux with systemctl: what to check before shutting down the server

Débutant5 min de lecture
À retenirLinux n'est pas réservé aux experts. Le bon point de départ : une distribution accessible, une sauvegarde propre et quelques commandes comprises.

Restarting a Linux server with systemctl rebootIt seems simple. One command, one sudo password, and the machine restarts. The problem is that this restart also closes open sessions, SSH connections, running processes, and sometimes a service that someone was using.

I therefore advise you to treat a reboot like a minor maintenance task, even on a personal machine or a VPS. The goal is not to complicate a basic command, but to check what’s running, provide warnings if necessary, and then restart cleanly without discovering too late that a job was in progress.

Tux prepares a Linux server to restart with a glowing button

What systemctl reboot actually does

On a modern distribution with systemd, systemctl reboot It asks the system to restart the machine. It’s similar to a command. reboot, but you explicitly go through systemd, which orchestrates the shutdown of services before the restart.

sudo systemctl reboot

Not to be confused with systemctl poweroffwhich turns off the machine, or systemctl haltwhich shuts down the system without necessarily cutting power, depending on the hardware. If your goal is to reboot to apply a kernel update, reload a network stack, or check a service at boot, systemctl reboot is the direct command.

If you have simply modified a file .serviceA complete reboot isn’t always necessary. In that case, start by understanding instead. when to use systemctl daemon-reloadthen restart only the service in question.

Check open sessions before logging off

Before restarting a server, I first check who is connected. It’s silly, but it prevents accidentally disconnecting a colleague’s session, interrupting an SCP transfer, or disrupting a command launched from a terminal.

who
w
loginctl list-sessions

who provides a quick view of connected users. w adds what they do. loginctl list-sessions is useful on a systemd system, especially if you want to identify local, SSH or graphical sessions.

On a production server, I give a warning before restarting. A simple announcement is enough:

sudo wall "Server will restart in 10 minutes for maintenance."

If you’re the only one using a VPS, this step might seem unnecessary. However, I always keep it in mind whenever there are multiple accounts, client access, a long-running job, or an exposed application.

Monitor services and ongoing jobs

A clean reboot doesn’t fix everything. If a service was already malfunctioning before the reboot, it might revert to the same state afterward. I prefer to check beforehand and then compare afterward.

systemctl --failed
systemctl list-jobs
systemctl is-system-running

systemctl --failed lists the failed units. systemctl list-jobs shows pending systemd operations. systemctl is-system-running gives an overall state, for example running, degraded Or starting.

If you see a critical service failing, note its name before restarting:

systemctl status service-name
journalctl -u service-name -b --no-pager

To get a more comprehensive list of services and filter out what is active or malfunctioning, you can also refer to the guide on the… useful systemctl commands before a random rebootThis is exactly the kind of verification that avoids confusing cause and effect.

Plan a restart instead of shutting down immediately

systemctl reboot restarts immediately. If you want to allow a delay, use instead shutdown with the option -r. THE -r means reboot.

sudo shutdown -r +10 "Reboot expected in 10 minutes"

To cancel the scheduled restart:

sudo shutdown -c

This is my preferred method when there’s the slightest doubt. You keep a few minutes to complete a backup, close a session, notify a user, or check a monitoring system.

The documentation of shutdown It remains useful if you want to understand the accepted time formats. For systemctlThe systemd reference is available in the official systemctl page.

SSH case: do not restart without a safety net

If you are connected via SSH, the reboot will disconnect your session. This isn’t a problem if the server restarts correctly. It becomes a problem if the network, firewall, disk, or SSH don’t go back up.

  • Maintain console, KVM, IPMI, iDRAC, iLO or vendor console access if possible.
  • Check the disk space before restarting if the machine has already shown errors.
  • Avoid restarting immediately after an untested network change.
  • If you have modified the firewall, keep a return rule or a local root session.

On a VPS, I also check that the provider’s web console is working before running the command. It takes 30 seconds and can save you a frustrating support request.

After rebooting, check that the machine has returned to normal operation.

Once reconnected, don’t assume everything is fine just because SSH is responding. Start by checking the last boot:

uptime
systemctl is-system-running
systemctl --failed

Then check for errors during the current boot process:

journalctl -b -p warning..alert --no-pager

If you want to compare with the previous startup, use:

journalctl -b -1 -p warning..alert --no-pager

The guide to journalctl and the last Linux boot This section details if you need to investigate a slow boot, a failed service, or a hardware message.

My checklist before a Linux reboot

  • who Or w to see the open sessions.
  • systemctl --failed to note the services that are already in error.
  • systemctl list-jobs to avoid interrupting a systemd operation that is currently running.
  • shutdown -r +10 if you want to allow a delay.
  • Console access if you are working remotely.
  • journalctl -b after restarting to check for errors.

On a test station, sudo systemctl reboot That’s often enough. On a server, I’d rather spend two minutes checking sessions and services than gain ten seconds chasing after a machine that doesn’t come back.

sudo apt update && sudo apt upgrade