Comprendre systemd

systemctl vous permet de contrôler les services Linux depuis le terminal. En 5 commandes, vous saurez démarrer Nginx, l'activer au boot et comprendre pourquoi un service refuse de démarrer. Ce guide vous accompagne du premier systemctl status jusqu'à la création de vos propres services.

Ce que vous allez apprendre

Niveau : Débutant · Durée : 20 minutes · Prérequis : accès root ou sudo

À la fin de ce guide, vous saurez :

• Démarrer, arrêter et redémarrer un service
• Activer un service au boot (et comprendre la différence avec "démarrer")
• Diagnostiquer pourquoi un service ne démarre pas
• Créer un service personnalisé pour votre application
• Sécuriser un service avec les directives de hardening

TL;DR — Les 5 commandes indispensables

# 1. État complet d'un service (le "status" détaillé)
sudo systemctl status nginx --no-pager -l

# 2. Démarrer / Arrêter / Redémarrer
sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx

# 3. Activer au boot (≠ démarrer maintenant !)
sudo systemctl enable nginx
sudo systemctl enable --now nginx  # enable + start en une commande

# 4. Voir les logs d'un service
journalctl -xeu nginx

# 5. Vérifier si un service tourne / est activé au boot
systemctl is-active nginx
systemctl is-enabled nginx

enable ≠ start

enable configure le service pour démarrer au prochain boot, mais ne le démarre pas maintenant. Pour démarrer immédiatement ET activer au boot, utilisez enable --now.

Glossaire rapide (2 minutes)

Avant d'aller plus loin, clarifions 5 termes qui créent 90% de la confusion :

Terme	Définition	Commande associée
Unit	Objet géré par systemd (service, timer, socket, mount...)	systemctl list-units
Service	Type d'unité .service — un processus qui tourne	systemctl status nginx.service
Active	Le service tourne maintenant	systemctl is-active nginx
Enabled	Le service démarrera au boot	systemctl is-enabled nginx
Drop-in	Petit fichier override sans toucher au fichier vendor	systemctl edit nginx

Glissez pour voir

Les deux états à ne pas confondre

systemd distingue deux notions d'état — c'est la source #1 de confusion pour les débutants :

État runtime (le service tourne-t-il maintenant ?)

État	Signification
active (running)	Le processus tourne
active (exited)	Le service s'est exécuté et terminé (normal pour certains oneshot)
inactive	Le service est arrêté
failed	Le service a crashé ou n'a pas pu démarrer

Glissez pour voir

État d'activation (démarre-t-il au boot ?)

État	Signification
enabled	Démarre automatiquement au boot
disabled	Ne démarre pas au boot
static	Pas de section [Install] — ne peut pas être enable directement
masked	Désactivé de force — impossible à démarrer même manuellement

Glissez pour voir

Commandes de vérification rapide

# État runtime
systemctl is-active nginx    # retourne "active" ou "inactive"

# État d'activation
systemctl is-enabled nginx   # retourne "enabled", "disabled", "static"...

Ces commandes sont parfaites pour les scripts : elles retournent un code de sortie utilisable.

Scénario 1 : Démarrer, arrêter, redémarrer un service

Démarrer un service

sudo systemctl start nginx

Vérifiez qu'il tourne :

systemctl is-active nginx
# active

Arrêter un service

sudo systemctl stop nginx

Redémarrer vs Recharger

Restart arrête puis redémarre le service (coupure de connexions) :

sudo systemctl restart nginx

Reload recharge la configuration sans couper les connexions (si le service le supporte) :

sudo systemctl reload nginx

Tous les services ne supportent pas reload

Certains services (comme Nginx) supportent reload, d'autres non. Pour ne pas avoir à y penser, utilisez la commande robuste :

sudo systemctl reload-or-restart nginx

Cette commande fait un reload si supporté, sinon un restart.

La commande la plus sûre en ops

# Reload si possible, sinon restart — mais seulement si le service tourne déjà
sudo systemctl try-reload-or-restart nginx

Cette commande ne fait rien si le service est arrêté (évite de démarrer par accident un service désactivé).

Scénario 2 : Activer un service au boot

Activer sans démarrer

sudo systemctl enable nginx

Le service démarrera au prochain boot, mais ne démarre pas maintenant.

Activer ET démarrer

sudo systemctl enable --now nginx

Désactiver

sudo systemctl disable nginx        # ne démarre plus au boot
sudo systemctl disable --now nginx  # désactive ET arrête

Bloquer complètement un service (mask)

sudo systemctl mask nginx     # impossible à démarrer, même manuellement
sudo systemctl unmask nginx   # annule le mask

mask est utile pour s'assurer qu'un service dangereux ou obsolète ne puisse jamais être démarré par erreur.

Scénario 3 : Comprendre pourquoi ça ne démarre pas

Quand un service refuse de démarrer, suivez ce workflow de dépannage :

1. Voir l'état complet

   sudo systemctl status nginx --no-pager -l

   L'option --no-pager -l évite la troncature et affiche tout.

2. Consulter les logs avec contexte

   journalctl -xeu nginx

   • -x : ajoute des explications
   • -e : va à la fin des logs
   • -u nginx : filtre sur l'unité nginx

3. Voir le fichier unit et ses overrides

   systemctl cat nginx

   Cette commande affiche le fichier complet avec les drop-ins appliqués.

4. Inspecter les propriétés clés

   systemctl show nginx -p ExecStart -p FragmentPath -p DropInPaths

   Vous verrez exactement quel fichier est utilisé et quelle commande est exécutée.

Filtrer les logs par période

# Logs du boot actuel
journalctl -u nginx -b

# Logs des dernières 30 minutes
journalctl -u nginx --since "30 min ago"

# Logs entre deux timestamps
journalctl -u nginx --since "2026-01-29 10:00" --until "2026-01-29 11:00"

# Uniquement les erreurs
journalctl -u nginx -p err

Scénario 4 : Créer un service personnalisé

Vous avez un script Python ou une application que vous voulez lancer au boot ? Créez un fichier .service.

Exemple : service pour une app Python

1. Créer le fichier unit

   sudo systemctl edit --full --force mon-app.service

   Ou créez directement dans /etc/systemd/system/mon-app.service :

   

   [Unit]
   Description=Mon application Python
   After=network.target
   
   [Service]
   Type=simple
   User=www-data
   Group=www-data
   WorkingDirectory=/opt/mon-app
   ExecStart=/opt/mon-app/venv/bin/python app.py
   Restart=on-failure
   RestartSec=5s
   
   [Install]
   WantedBy=multi-user.target

2. Recharger la configuration systemd

   sudo systemctl daemon-reload

   Obligatoire après toute modification de fichier unit.

3. Activer et démarrer

   sudo systemctl enable --now mon-app

4. Vérifier

   systemctl status mon-app
   journalctl -u mon-app -f  # suivre les logs en temps réel

Les directives essentielles

Directive	Section	Description
Description=	[Unit]	Description lisible du service
After=	[Unit]	Démarrer après ces unités
Requires=	[Unit]	Dépendance forte (si l'autre échoue, celui-ci aussi)
Wants=	[Unit]	Dépendance faible (on essaie de démarrer l'autre)
Type=	[Service]	simple, forking, oneshot, notify
ExecStart=	[Service]	Commande de démarrage
ExecReload=	[Service]	Commande de reload (optionnel)
Restart=	[Service]	no, on-failure, always
RestartSec=	[Service]	Délai avant restart
User= / Group=	[Service]	Utilisateur d'exécution
WantedBy=	[Install]	Target qui "tire" ce service

Glissez pour voir

Modifier un service existant (sans toucher au vendor)

Ne modifiez jamais les fichiers dans /usr/lib/systemd/system/ — ils seront écrasés à la prochaine mise à jour du paquet.

Utilisez plutôt les drop-ins :

sudo systemctl edit nginx

Cela crée /etc/systemd/system/nginx.service.d/override.conf. Ajoutez uniquement ce que vous voulez changer :

[Service]
# Augmenter le nombre de fichiers ouverts
LimitNOFILE=65535

Puis rechargez :

sudo systemctl daemon-reload
sudo systemctl restart nginx

Où sont les fichiers unit ?

Les chemins varient selon les distributions (Debian vs RHEL vs Arch), mais la règle d'or est de ne pas apprendre par chemin :

# Voir le chemin exact d'une unité
systemctl cat nginx | head -1

# Ou avec show
systemctl show nginx -p FragmentPath

Emplacement	Usage
/usr/lib/systemd/system/	Units fournies par les paquets (ne pas modifier)
/lib/systemd/system/	Idem (lié à /usr/lib sur certaines distros)
/etc/systemd/system/	Vos units personnalisées et overrides
/run/systemd/system/	Units runtime (temporaires)

Glissez pour voir

Priorité : /etc/ > /run/ > /usr/lib/

Timers : remplacer cron par systemd

Les timers (.timer) sont l'alternative moderne à cron. Avantages : logs centralisés, dépendances, pas de chevauchement.

Exemple : nettoyage quotidien

Créez /etc/systemd/system/cleanup.service :

[Unit]
Description=Nettoyage des fichiers temporaires

[Service]
Type=oneshot
ExecStart=/usr/local/bin/cleanup.sh

Puis /etc/systemd/system/cleanup.timer :

[Unit]
Description=Lance le nettoyage tous les jours à 3h

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

Activez le timer (pas le service) :

sudo systemctl enable --now cleanup.timer

Vérifiez les timers actifs :

systemctl list-timers

Sécurité : durcir un service

systemd offre des directives de sandboxing puissantes. Voici un exemple de service durci :

[Service]
# Utilisateur non-root
User=mon-app
DynamicUser=yes

# Isolation filesystem
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
ReadWritePaths=/var/lib/mon-app

# Isolation réseau et capabilities
NoNewPrivileges=yes
CapabilityBoundingSet=
RestrictAddressFamilies=AF_INET AF_INET6

# Restrictions système
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectControlGroups=yes

Mesurer la sécurité d'un service

systemd-analyze security nginx

Cette commande donne un score de 0 à 10 (10 = le plus exposé) et suggère des améliorations :

→ Overall exposure level for nginx.service: 9.2 UNSAFE 😨

  NAME                            DESCRIPTION                              EXPOSURE
✓ PrivateNetwork=                 Service has access to the host's network      0.5
✗ User=/DynamicUser=              Service runs as root                          0.4
✗ CapabilityBoundingSet=~CAP_...  Service has dangerous capabilities            0.3
...

Appliquez les recommandations une par une et re-testez.

Recettes du quotidien

Ces commandes couvrent l'essentiel de l'administration quotidienne d'un service. Gardez-les sous la main : elles répondent à 90 % des besoins courants.

État complet d'un service

Voir si le service tourne, ses logs récents et son PID en un coup d'œil.

sudo systemctl status SERVICE --no-pager -l
# Exemple
sudo systemctl status nginx --no-pager -l

SERVICE est le nom du service, avec ou sans le suffixe .service.

Activer ET démarrer

Activer au boot et démarrer immédiatement, en une seule commande.

sudo systemctl enable --now SERVICE
# Exemple
sudo systemctl enable --now nginx

Reload ou restart robuste

Recharger la configuration si le service le supporte, sinon le redémarrer.

sudo systemctl reload-or-restart SERVICE
# Exemple
sudo systemctl reload-or-restart nginx

Voir le fichier unit complet

Afficher le fichier unit avec tous les drop-ins appliqués — la vraie configuration effective.

systemctl cat SERVICE
# Exemple
systemctl cat nginx

Override propre via drop-in

Modifier un service sans toucher au fichier vendor, qui serait écrasé à la prochaine mise à jour.

sudo systemctl edit SERVICE
# Exemple
sudo systemctl edit nginx

Logs d'un service

Voir les logs avec contexte et explications, pour comprendre un échec.

journalctl -xeu SERVICE
# Exemple
journalctl -xeu nginx

Suivre les logs en temps réel

L'équivalent de tail -f pour les logs systemd.

journalctl -u SERVICE -f
# Exemple
journalctl -u nginx -f

Lister les services en échec

Repérer immédiatement ce qui ne va pas sur le système.

systemctl list-units --failed

Recharger la configuration systemd

Obligatoire après toute modification d'un fichier unit.

sudo systemctl daemon-reload

Auditer la sécurité d'un service

Obtenir un score de sécurité et des recommandations concrètes.

systemd-analyze security SERVICE
# Exemple
systemd-analyze security nginx

Services les plus lents au boot

Identifier les services qui ralentissent le démarrage du système.

systemd-analyze blame | head -10

Bloquer un service

Empêcher un service de démarrer, même manuellement.

sudo systemctl mask SERVICE
# Exemple
sudo systemctl mask cups

Pour débloquer ensuite : sudo systemctl unmask SERVICE.

Pièges courants

Ces erreurs reviennent constamment chez les débutants comme chez les opérateurs pressés. Les connaître évite des services qui « ne démarrent pas » sans raison apparente.

Confondre enable et start

sudo systemctl enable nginx

Symptôme : le service n'est toujours pas démarré après la commande.

Cause : enable configure le démarrage au boot, mais ne démarre rien maintenant.

sudo systemctl enable --now nginx

Oublier daemon-reload

Vous modifiez /etc/systemd/system/mon-app.service puis lancez directement un restart.

Symptôme : les modifications ne sont pas prises en compte.

Cause : systemd garde la configuration en cache — il faut explicitement la recharger.

sudo systemctl daemon-reload && sudo systemctl restart mon-app

Modifier le fichier vendor

sudo vim /usr/lib/systemd/system/nginx.service

Symptôme : les modifications disparaissent à la prochaine mise à jour du paquet.

Cause : les fichiers vendor sont écrasés par les mises à jour. Il faut passer par un drop-in.

sudo systemctl edit nginx

Reload sur un service qui ne le supporte pas

sudo systemctl reload mon-app

Symptôme : erreur Job failed, ou service qui n'applique pas la nouvelle configuration.

Cause : tous les services ne réagissent pas au signal de reload.

sudo systemctl reload-or-restart mon-app

WorkingDirectory inexistant

WorkingDirectory=/opt/mon-app

Symptôme : service en failed avec No such file or directory.

Cause : le dossier n'existe pas, ou n'est pas accessible par l'utilisateur d'exécution. Vérifiez que le dossier existe et porte les bonnes permissions avant de démarrer le service.

Chemin relatif dans ExecStart

ExecStart=./app.py

Symptôme : service en failed avec Executable path is not absolute.

Cause : systemd exige des chemins absolus dans ExecStart.

ExecStart=/opt/mon-app/venv/bin/python /opt/mon-app/app.py

Pas de section [Install]

Vous créez un service sans directive WantedBy=.

Symptôme : systemctl enable retourne static — l'activation ne fait rien.

Cause : sans section [Install], systemd ne sait pas à quel moment du boot accrocher le service. Ajoutez une section [Install] avec WantedBy=multi-user.target.

Au-delà des services : les autres types d'unités

systemd gère bien plus que des services. Voici les types d'unités les plus utiles :

Type	Extension	Usage
Service	.service	Processus en arrière-plan
Timer	.timer	Tâches planifiées (remplace cron)
Socket	.socket	Activation à la demande (le service démarre quand quelqu'un se connecte)
Mount	.mount	Points de montage
Target	.target	Groupes d'unités (comme multi-user.target)
Path	.path	Surveillance de fichiers/dossiers

Glissez pour voir

Lister toutes les unités d'un type :

systemctl list-units --type=timer
systemctl list-units --type=socket

Performance boot

Analyser le temps de démarrage :

# Temps total
systemd-analyze

# Services les plus lents
systemd-analyze blame | head -15

# Graphe des dépendances
systemd-analyze plot > boot.svg

blame peut être trompeur

Un service lent au boot n'est pas forcément "le coupable" — il peut attendre une dépendance. Utilisez systemd-analyze critical-chain pour voir la chaîne critique.

Ce qu'il faut retenir

enable ≠ start : enable configure le boot, start démarre maintenant. Utilisez enable --now pour les deux.

Ne modifiez jamais /usr/lib/ : utilisez systemctl edit pour créer des drop-ins propres.

daemon-reload obligatoire : après toute modification de fichier unit.

reload-or-restart : la commande robuste qui marche toujours.

Workflow de debug : status --no-pager -l → journalctl -xeu → systemctl cat → systemctl show.

Sécurité mesurable : systemd-analyze security donne un score et des recommandations.

Prochaines étapes

Journalctl en détail Maîtriser les logs systemd : filtres, exports, rotation

Services Linux Approfondir la gestion des services

Timers systemd Remplacer cron par des timers modernes

Sécurisation Linux Durcir votre système au-delà de systemd

Ressources officielles

• systemd.io — documentation officielle
• Manpage systemctl — référence complète
• Manpage systemd.service — directives de fichier unit
• Manpage systemd-analyze — analyse et sécurité

×

📖 Voir la documentation →