Maîtriser systemctl : la commande de gestion de systemd

1. Consultez le statut d'un service

systemctl status nginx

Cela indique si le service est actif (`active (running)`), inactif (`inactive`), en échec ou `masked`. En dessous, vous voyez les dernières lignes de journal du service — une première impression rapide sans devoir ouvrir `journalctl`.

2. Démarrez un service directement

sudo systemctl start nginx

Cela démarre le service maintenant, mais pas au prochain démarrage du système. Pour un serveur web qui doit tourner après un reboot, vous avez besoin de l'étape 3.

3. Activez un service au démarrage

sudo systemctl enable nginx

Cela crée un lien symbolique du fichier unit vers le `multi-user.target` — le système démarre désormais le service automatiquement.

4. Démarrez et activez en une seule fois

sudo systemctl enable --now nginx

L'option `--now` combine les étapes 2 et 3. Pour un nouveau service, c'est presque toujours ce que vous voulez : tourner maintenant et après un reboot.

5. Arrêtez un service

sudo systemctl stop nginx

Cela arrête le service immédiatement. Utilisez `disable` pour également désactiver le démarrage automatique au boot.

6. Redémarrez un service

sudo systemctl restart nginx

Cela arrête puis redémarre le service. Pratique après une modification de configuration, mais cela interrompt les connexions actives. Pour nginx et d'autres services qui rechargent leur configuration sans s'arrêter, `reload` est le meilleur choix :

sudo systemctl reload nginx

`reload` envoie le signal que le service a lui-même défini pour relire sa configuration — sans interruption de service.

Mask : rendre un service impossible à démarrer

Parfois, un service ne doit pas seulement être arrêté, mais aussi ne pas pouvoir être démarré — ni par vous, ni par un autre service qui en dépend.

sudo systemctl mask nginx

Cela lie le fichier unit vers `/dev/null`. Toute tentative de démarrage du service échoue, même indirectement via les dépendances. Avec `unmask`, vous annulez cela :

sudo systemctl unmask nginx

C'est plus strict que `disable` : un service désactivé peut encore être démarré par un autre service qui en a besoin. Un service masqué, lui, ne le peut pas.

Gérer les services des utilisateurs

Tout ne doit pas être fait en root. Avec le flag `--user`, vous gérez les services qui tournent sous votre propre compte utilisateur :

systemctl --user status mon-service
systemctl --user enable --now mon-service

Cela fonctionne pour les processus en arrière-plan comme un minuteur de sauvegarde personnel ou un serveur de développement. Les services se trouvent dans `~/.config/systemd/user/`. Vous n'avez pas besoin de sudo pour cela.

Targets : le runlevel moderne

Une target dans systemd remplace le runlevel de l'ancien SysV init. Là où vous utilisiez `telinit 3` pour passer en mode multi-user, vous utilisez maintenant :

sudo systemctl isolate multi-user.target

Cela désactive tous les services qui ne se trouvent pas dans cette target. `multi-user.target` est le mode texte sans interface graphique ; `graphical.target` est l'équivalent avec environnement de bureau. Les anciennes commandes comme `telinit` fonctionnent encore, mais elles envoient en interne des commandes systemd.

La structure de systemctl

La forme de base est prévisible :

systemctl [options] [commande] [unit]

Les options les plus utilisées :

• `--now` : démarre ou arrête immédiatement lors d'un enable ou disable
• `--no-block` : n'attend pas la fin de l'action
• `--force` : force l'action, même si le service ne répond pas

Vérification

Vérifiez que tout fonctionne :

systemctl status nginx
systemctl is-enabled nginx
systemctl is-active nginx

`is-enabled` indique si le service démarre au boot ; `is-active` indique s'il tourne actuellement. Les deux devraient afficher `enabled` et `active`.

Problèmes fréquents

1. Le service ne démarre pas après une modification de configuration

sudo systemctl daemon-reload

Systemd met en cache les fichiers unit. Après avoir modifié un fichier unit dans `/etc/systemd/system/`, vous devez recharger le démon, sinon il utilise l'ancienne configuration.

2. Le service continue d'échouer — pas de message d'erreur clair

sudo journalctl -u nginx -n 50

`systemctl status` n'affiche que les dernières lignes de journal. `journalctl` donne la sortie complète du service, souvent avec l'erreur réelle qui reste sinon cachée.

3. Un service est masqué et vous ne savez pas pourquoi

systemctl list-unit-files | grep masked

Cela affiche toutes les unités masquées. Un service `masked` ne peut pas être démarré, même par des dépendances. Cela est parfois nécessaire, mais peut être déroutant si un service dépendant ne démarre pas.

Ce que systemctl vous coûte

Systemd n'est pas le système init le plus minimaliste qui soit. Les critiques sur la complexité sont justifiées : là où SysV init reposait sur de simples scripts shell, systemd fonctionne avec son propre format de configuration, son propre démon de journalisation et son propre gestionnaire de services. Celui qui voulait simplement taper `service nginx start` doit maintenant connaître la différence entre `start`, `enable` et `mask`.

La complexité achète quand même quelque chose : démarrage en parallèle, meilleur suivi des dépendances et une interface uniforme pour les services, les minuteries, les montages et la gestion de l’alimentation. Les anciennes commandes `service` et `chkconfig` fonctionnent encore sur la plupart des distributions, mais elles pilotent en interne simplement systemd.

En wie systemd niet wil, heeft een probleem: alternatieven zoals OpenRC of runit bestaan, maar de grote distributies zijn overgestapt. Zelfs als je een alternatief init-systeem draait, moet je software vaak configureren die rekening houdt met systemd-componenten. De keuze is in de praktijk gemaakt.

`systemctl` n’est dès lors plus une option, mais la norme — et qui gère Linux ne peut plus l’ignorer.