Gérer les services systemd sous Linux : guide complet

Sur pratiquement tous les serveurs Linux modernes, des processus d’arrière-plan tels que les serveurs web, les bases de données et les services de messagerie fonctionnent via systemd. Avec systemd, vous gérez ces services : les démarrer, les arrêter, les redémarrer, les faire démarrer automatiquement et vérifier qu’ils fonctionnent correctement. Dans cet article, vous découvrirez les principales commandes, comment consulter les logs et comment créer votre propre service, afin de pouvoir résoudre vous-même les incidents sans devoir immédiatement appeler votre hébergeur.

Qu’est-ce que systemd et pourquoi est-ce important

Systemd est le système d’initialisation qui démarre en premier sur la plupart des distributions Linux (Ubuntu, Debian, CentOS, AlmaLinux) et qui gère ensuite tous les autres services. Pensez au serveur web (LiteSpeed ou Apache), au serveur de base de données (MySQL/MariaDB), à SSH et aux tâches cron. Chaque service fonctionne en tant qu’unit, avec un fichier de configuration qui décrit comment et quand le service doit démarrer.

L’avantage de systemd est qu’il permet de gérer tous les services avec un seul ensemble de commandes cohérent, quel que soit le logiciel sous-jacent. Cela rend la gestion claire et prévisible, aussi bien sur un VPS personnel que sur un serveur géré.

Commandes de base pour gérer les services

Toutes les commandes systemd passent par systemctl. Voici les principales commandes dont vous aurez besoin pour gérer un service, par exemple nginx, mariadb ou sshd.

• systemctl status nginx – affiche le statut actuel du service
• systemctl start nginx – démarre le service
• systemctl stop nginx – arrête le service
• systemctl restart nginx – redémarre complètement le service
• systemctl reload nginx – recharge la configuration sans couper les connexions
• systemctl enable nginx – fait en sorte que le service démarre automatiquement au démarrage du serveur
• systemctl disable nginx – désactive le démarrage automatique

La plupart des commandes nécessitent des droits root, utilisez donc sudo devant si vous n’êtes pas connecté en tant que root.

Consulter les logs et diagnostiquer les problèmes

Lorsqu’un service ne démarre pas ou s’arrête de manière inattendue, systemctl status donne souvent déjà un premier indice. Pour des logs plus détaillés, utilisez journalctl, le service de logs centralisé de systemd.

• journalctl -u nginx – affiche toutes les lignes de log du service nginx
• journalctl -u nginx -f – suit les logs en direct, pratique pendant les tests
• journalctl -u nginx --since "1 hour ago" – filtre par période
• journalctl -p err – affiche uniquement les messages d’erreur de tous les services

Si un service se bloque systématiquement peu après son démarrage, vérifiez que la configuration est valide (par exemple avec nginx -t pour nginx) avant de redémarrer le service. Si vous utilisez un serveur avec Plesk, vous pouvez également consulter bon nombre de ces statuts de manière graphique via le panneau Plesk, y compris le redémarrage des services sans terminal.

Créer son propre service systemd

Si vous faites tourner votre propre application ou script qui doit toujours rester actif, vous pouvez créer un fichier unit personnalisé pour cela. Créez un fichier dans /etc/systemd/system/monapp.service avec au minimum le contenu suivant :

• [Unit] avec une description et des dépendances (par exemple le réseau)
• [Service] avec la commande pour démarrer l’application, la politique de redémarrage et éventuellement l’utilisateur sous lequel le processus doit s’exécuter
• [Install] avec la cible (généralement multi-user.target) afin que le service démarre automatiquement

Après la création, exécutez systemctl daemon-reload afin que systemd reconnaisse le nouveau fichier, puis systemctl enable --now monapp pour démarrer le service et le faire démarrer automatiquement.

Si vous gérez plusieurs services personnalisés sur un VPS, il est intéressant de définir une politique de redémarrage claire (Restart=on-failure), afin que le service se rétablisse automatiquement en cas de crash. Si vous avez des doutes sur les bons réglages pour votre environnement hébergement web, consultez la base de connaissances pour plus d’informations.