fren
Connexion

Redémarrer, arrêter et vérifier son VPS

3 min de lecture07 novembre 2026

Un redémarrage semble anodin, mais il coupe les transferts en cours, interrompt les transactions et peut révéler un service mal configuré qui ne revient pas. Sur un VPS, il existe deux voies : la commande depuis le système, propre et ordonnée, et l'action du panneau, qui peut être forcée. La seconde ne doit servir qu'en dernier recours.

Redémarrer proprement

Bash
sudo systemctl reboot

sudo reboot fonctionne aussi et passe par systemd sur Debian 13. Pour prévenir et retarder :

Bash
sudo shutdown -r +5 "Redémarrage de maintenance"
sudo shutdown -c

La première commande programme un redémarrage dans cinq minutes et affiche un message aux utilisateurs connectés ; la seconde annule. Avant de lancer, vérifiez qui est connecté avec who et prévenez avec wall si d'autres personnes utilisent la machine.

Pour une base de données, arrêtez d'abord les services qui écrivent :

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

L'arrêt de la base force l'écriture des données en attente. systemd arrête de toute façon les unités dans l'ordre, mais un arrêt explicite rend la séquence visible et plus sûre.

Arrêter et utiliser le panneau

Bash
sudo shutdown -h now
sudo systemctl poweroff

Ces commandes éteignent la machine. Depuis https://dash.neoheberg.fr, le panneau VPS propose les actions d'alimentation et la console noVNC. Une extinction forcée depuis le panneau coupe le conteneur sans laisser aux services le temps de terminer : utilisez-la seulement si le système ne répond plus.

Après une extinction forcée, le système de fichiers journalisé rejoue généralement ses opérations au démarrage. Ne lancez pas fsck sur un système monté : cela peut aggraver les dégâts.

Vérifier après démarrage

Bash
uptime -s
last reboot | head
systemctl --failed
journalctl -b -p err
ss -tlnp
  • uptime -s donne l'heure de démarrage.
  • systemctl --failed liste les unités en échec ; l'objectif est une sortie vide.
  • journalctl -b -p err montre les erreurs du démarrage courant.
  • ss -tlnp confirme que les ports attendus écoutent.

Testez ensuite le service de bout en bout : une requête HTTP, une connexion SSH, une requête DNS. Un port ouvert ne prouve pas que l'application répond correctement. Si un service est enabled mais arrêté, systemctl status nom et journalctl -u nom donnent la cause.

Quand ne pas redémarrer

Un disque plein, une erreur de configuration Nginx ou un conflit de port ne se règlent pas par un redémarrage. Dans ces cas, le service reviendra en échec et vous aurez perdu du temps. Diagnostiquez d'abord.

Si le VPS redémarre en boucle, ouvrez la console et consultez le démarrage précédent :

Bash
journalctl -b -1 -p err
  • Planifiez les redémarrages de maintenance, surtout après une mise à jour de bibliothèques système.
  • Vérifiez que les services critiques sont enabled, pas seulement démarrés à la main.
  • Gardez une sauvegarde récente avant toute opération sur l'alimentation.
  • Sur un conteneur système, le noyau reste géré par la plateforme : un redémarrage du conteneur ne le met pas à jour.

Vérifier

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

is-system-running doit répondre running, ou degraded avec une cause identifiée. Un état degraded n'est pas normal : listez les unités en échec et corrigez-les avant de considérer le redémarrage terminé.

Publicité

Cet article vous a-t-il aidé ?

À lire aussi