fren
Connexion

Gérer ses services avec systemd

2 min de lecture07 novembre 2026

Sur Debian 13, systemd démarre les services, les surveille et centralise leurs journaux. Savoir le piloter évite de redémarrer tout le VPS pour relancer Nginx ou une application. Ces commandes sont celles de systemd sur Debian 13.

Les commandes de base

Action Commande
État détaillé systemctl status nginx
Démarrer maintenant sudo systemctl start nginx
Arrêter maintenant sudo systemctl stop nginx
Redémarrer sudo systemctl restart nginx
Recharger la configuration sudo systemctl reload nginx
Activer au démarrage sudo systemctl enable nginx
Désactiver au démarrage sudo systemctl disable nginx
Voir les échecs systemctl --failed

start agit immédiatement, enable crée le lien qui lance le service au boot. Les deux sont indépendants : un service peut tourner sans être activé, et inversement. reload est préférable à restart quand le logiciel relit sa configuration sans couper les connexions ; nginx -t doit toujours précéder un rechargement.

Pour lister ce qui tourne réellement :

Bash
systemctl list-units --type=service --state=running
systemctl is-enabled nginx

Créer une unité pour son application

Une application lancée à la main s'arrête à la fermeture du terminal. Une unité la fait démarrer au boot et la redémarre en cas de plantage. Créez /etc/systemd/system/mon-app.service :

INI
[Unit]
Description=Mon application Node.js
After=network.target

[Service]
Type=simple
User=app
WorkingDirectory=/srv/mon-app
EnvironmentFile=/etc/mon-app.env
ExecStart=/usr/bin/node /srv/mon-app/index.js
Restart=on-failure
RestartSec=5
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

ExecStart exige un chemin absolu et ne passe pas par un shell. EnvironmentFile doit être lisible par l'utilisateur du service, avec des permissions 600 s'il contient des secrets. Restart=on-failure évite de relancer en boucle un service qui sort proprement.

Activez ensuite :

Bash
sudo systemctl daemon-reload
sudo systemctl enable --now mon-app
sudo systemctl status mon-app

daemon-reload est obligatoire après toute modification d'une unité.

Lire l'état et les journaux

Bash
systemctl status mon-app --no-pager
journalctl -u mon-app -f
journalctl -u mon-app --since "30 min ago" -p err

status affiche le code de sortie, le PID principal et les dernières lignes. Un état activating (auto-restart) signale une boucle de redémarrage : lisez les lignes juste avant le message d'échec. Après correction, sudo systemctl reset-failed mon-app efface le compteur d'échecs.

Bonnes pratiques

  • Ne modifiez pas les unités fournies par les paquets. Utilisez sudo systemctl edit nginx pour créer un fichier de surcharge dans /etc/systemd/system/nginx.service.d/.
  • Utilisez systemctl mask plutôt que disable pour empêcher un service de démarrer, même comme dépendance.
  • Après un changement, testez un redémarrage complet du VPS et vérifiez systemctl --failed.

Vérifier

Bash
systemctl is-active mon-app
systemctl is-enabled mon-app
systemctl show -p MainPID -p Restart mon-app

is-active doit répondre active, is-enabled doit répondre enabled, et le PID doit changer après un restart. Si le service redémarre sans cesse, cherchez l'erreur dans journalctl -u mon-app -n 100 avant de modifier l'unité.

Publicité

Cet article vous a-t-il aidé ?

À lire aussi