fren
Log In

Reboot, stop and check a VPS

3 min read07 November 2026

A reboot looks harmless, but it cuts ongoing transfers, interrupts transactions and can reveal a misconfigured service that does not come back. On an VPS there are two paths: the command from inside the system, clean and orderly, and the panel action, which can be forced. The second is a last resort.

Reboot cleanly

Bash
sudo systemctl reboot

sudo reboot also works and goes through systemd on Debian 13. To warn users and delay:

Bash
sudo shutdown -r +5 "Maintenance reboot"
sudo shutdown -c

The first schedules a reboot in five minutes and shows a message to logged-in users; the second cancels it. Before running it, check who is connected with who and warn them with wall if others use the machine.

For a database, stop writing services first:

Bash
sudo systemctl stop nginx
sudo systemctl stop mariadb
sudo systemctl reboot

Stopping the database flushes pending data. systemd stops units in order anyway, but an explicit stop makes the sequence visible and safer.

Stop and use the panel

Bash
sudo shutdown -h now
sudo systemctl poweroff

These power the machine off. From https://dash.neoheberg.fr, the VPS panel offers power actions and the noVNC console. A forced stop from the panel cuts the container without giving services time to finish: use it only when the system is unresponsive.

After a forced stop, a journaling filesystem usually replays its operations at boot. Do not run fsck on a mounted filesystem: it can make things worse.

Check after boot

Bash
uptime -s
last reboot | head
systemctl --failed
journalctl -b -p err
ss -tlnp
  • uptime -s gives the boot time.
  • systemctl --failed lists failed units; the goal is empty output.
  • journalctl -b -p err shows errors from the current boot.
  • ss -tlnp confirms expected ports are listening.

Then test the service end to end: an HTTP request, an SSH login, a DNS query. An open port does not prove the application answers correctly. If a service is enabled but stopped, systemctl status name and journalctl -u name give the cause.

When not to reboot

A full disk, an Nginx configuration error or a port conflict will not be fixed by a reboot. In those cases the service fails again and you lose time. Diagnose first.

If the VPS reboots in a loop, open the console and read the previous boot:

Bash
journalctl -b -1 -p err
  • Schedule maintenance reboots, especially after a system library update.
  • Make sure critical services are enabled, not just started by hand.
  • Keep a recent backup before any power operation.
  • In a system container the kernel remains managed by the platform: rebooting the container does not update it.

Verify

Bash
systemctl is-system-running
systemctl --failed
curl -I http://localhost

is-system-running must answer running, or degraded with an identified cause. A degraded state is not normal: list failed units and fix them before considering the reboot complete.

Advertisement

Was this article helpful?

Read next