Déboguer les dépendances de services systemd : journalctl, systemctl et analyse de coredumps

Qui, en exploitation, doit déboguer des dépendances de services systemd, a besoin d’une procédure de vérification structurée plutôt que de redémarrages frénétiques. Ce runbook s’adresse aux administrateurs, System Engineers et opérateurs : il combine systemctl (statut et graphe de dépendances), journalctl (logs enrichis de contexte) et coredumpctl (analyse des crashs) en une séquence de dépannage exploitable avec modèles de cause, risques, étapes de vérification et stratégies de repli claires.

Pourquoi les dépendances sont souvent la cause réelle

Dans systemd, chaque Unit (p. ex. .service, .socket, .mount, .target) représente un état souhaité. Les dépendances déterminent quelles Units seront démarrées et dans quel ordre. Il est crucial de distinguer l’ordre (After=/Before=) de la liaison (Wants=/Requires=) : l’ordre indique seulement qui démarre après qui ; la liaison définit si une Unit impose le démarrage d’une autre ou est arrêtée en cas d’échec de celle-ci. Des dépendances modélisées de manière erronée provoquent des retards de démarrage, des conditions de course, des boucles de redémarrage ou des services « active » sans fournir de fonctionnalité.

Première évaluation : déterminer la classe de symptôme

Au départ, clarifiez : la Unit ne démarre pas, RESTe-t-elle en cours d’activation, fonctionne-t-elle sans fournir de fonctionnalité ou plante-t-elle ? Cette classification détermine si vous devez prioritairement examiner les dépendances, les ressources (mounts, ports) ou les erreurs de processus.

Le service ne démarre pas ou RESTe en « activating »

Causes principales : étapes ExecStartPre bloquantes, mounts manquants, timeouts ou jobs qui attendent d’autres Units. Identifiez d’abord si systemd attend une condition préalable ou si une commande de démarrage échoue.

Le service tourne, mais la fonctionnalité est absente

Souvent seul l’ordre est défini (After=), mais pas la garantie de démarrage (Wants=/Requires=), ou le service a écrit avant le montage d’une ressource. Vérifiez que les ressources nécessaires existent réellement et sont accessibles.

Le service plante ou redémarre indéfiniment

Les logs et les core dumps sont centraux ici. Les dépendances peuvent néanmoins être en jeu si le processus plante faute d’une ressource (p. ex. base de données). Distinguez un crash provoqué par un signal (p. ex. SIGSEGV) d’un OOM-kill du noyau.

Étape 1 : systemctl status — rapide, mais ciblé

systemctl status fournit les codes de sortie, compteurs de redémarrage, informations de déclenchement et les dernières lignes de log. C’est le premier regard, mais cela ne remplace pas la chaîne d’investigation suivante.

systemctl status --no-pager --full meinservice.service

Faites attention à :

• Active: Pour les daemons attendus, active (running) est correct ; active (exited) est correct pour Type=oneshot, mais suspect pour des daemons.
• ExecStart / ExecStartPre: un code de sortie différent de 0 indique une erreur de configuration ou de ressource.
• TriggeredBy: indications d’activation par socket ou par path.
• StartLimit: les limites de taux empêchent les redémarrages infinis.

Étape 2 : rendre les dépendances visibles

Distinguez quelles Units doivent être démarrées (Wants/Requires) et lesquelles ne sont définies que pour l’ordre (After/Before). Cela montre si systemd assure une condition préalable ou se contente d’attendre.

systemctl list-dependencies --all meinservice.service
systemctl list-dependencies --all --reverse meinservice.service
systemctl show meinservice.service -p Wants -p Requires -p After -p Before -p ExecStart -p Type -p RESTart

Interprétation: Si quelque chose figure dans After= mais pas dans Wants/Requires=, il n’existe qu’un ordre, pas de garantie de démarrage. Si Requires= est défini, le démarrage échoue en cas d’erreur de la dépendance — à utiliser consciemment lorsque l’absence de la condition préalable peut entraîner une perte de données.

Schritt 3: Jobs, Blockaden und kritische Kette

Les Jobs sont des actions planifiées ; des jobs en attente bloquent les chaînes. Utilisez list-jobs et systemd-analyze pour identifier les goulets d’étranglement.

systemctl list-jobs
systemd-analyze critical-chain
systemd-analyze blame

systemd-analyze critical-chain montre quelles unités retardent le chemin de démarrage — utile en cas de blocage du boot par des services Wait-Online ou des montages.

Schritt 4: journalctl gezielt einsetzen

Le journal combine horodatage, PID et contexte de l’unité. Filtrez volontairement, sinon vous vous perdrez dans les données. Travaillez le long de la chaîne : les logs du service concerné, puis ceux des unités qui bloquent.

journalctl -u meinservice.service -b --no-pager -n 200
journalctl -u meinservice.service --since "30 min ago" --no-pager
journalctl -u abhaengige-unit.service -b --no-pager -n 200

Utilisez les filtres de priorité de façon ciblée, mais vérifiez aussi les messages info, car de nombreux services consignent les erreurs uniquement en mode informatif.

Journal-Konfiguration, Limits und typische Stolperfallen

journald a des limites de configuration : espace limité, rate-limiting et transfert optionnel vers Syslog ou un serveur de logs externe. Si des logs manquent, vérifiez le stockage et les événements de rate-limit.

# Prüfen, ob persistentes Journal aktiv ist
ls -ld /var/log/journal || echo "kein persistent journal"
# Zeige journald-Konfiguration
cat /etc/systemd/journald.conf
# Journald-Usage ansehen
journalctl --disk-usage
# Alte Logs platzsparend entfernen
journalctl --vacuum-size=500M
journalctl --vacuum-time=7d

Remarque : le rate-limiting peut masquer de nombreuses erreurs récurrentes. Lors d’un incident, ne le désactivez pas systématiquement ; identifiez d’abord la cause et ne relevez les rate-limits qu’à titre expérimental.

Typische Fallen und schnelle Prüfungen

network.target vs. network-online.target

network.target signale seulement que la pile réseau est initialisée, pas nécessairement que le routage ou le DNS fonctionnent. network-online.target requiert un service wait-online ; si celui-ci est mal configuré, il bloque les chaînes de démarrage.

systemctl status --no-pager NetworkManager-wait-online.service
systemctl status --no-pager systemd-networkd-wait-online.service

Mounts: Pfad existiert, Storage fehlt

Les services écrivent parfois dans des répertoires locaux si un NAS/volume bloc est manquant — plus tard, le « jeu de données » disparaît lorsque le montage intervient ensuite. Utilisez RequiresMountsFor= pour garantir les montages.

findmnt -T /var/lib/meinservice
systemctl status --no-pager var-lib-meinservice.mount

Zyklische Abhängigkeiten

Des cycles de dépendances surviennent quand A dépend de B et B dépend indirectement de A. systemd signale de tels cycles ; résolvez-les par découplage (Wants statt Requires) ou en créant un target dédié comme coordinateur.

Socket-Activation

Pour les unités .socket, le service ne démarre qu’à la connexion. C’est efficace, mais cela peut perturber le monitoring : le service peut inactive alors que tout est correct.

systemctl status --no-pager meinservice.socket
systemctl status --no-pager meinservice.service
ss -lntp

Lorsqu’un service plante : utiliser coredumpctl en toute sécurité

Les core dumps fournissent des informations détaillées sur le plantage, mais peuvent contenir des données sensibles. Vérifiez les politiques de conservation et les permissions avant de générer ou de partager des dumps. systemd gère les dumps via systemd-coredump ; la configuration se trouve dans /etc/systemd/coredump.conf.

# Prüfe coredump-Konfiguration
cat /etc/systemd/coredump.conf 2>/dev/null || true
# Liste verfügbare Dumps für eine Unit
coredumpctl --no-pager list meinservice.service
# Detailansicht eines bestimmten Dumps
coredumpctl info PID

Pour l’analyse proprement dite, vous pouvez extraire le core ou l’ouvrir directement avec gdb. Les systèmes de production sont souvent dépourvus de symboles de débogage ; sans symboles, les traces de pile sont limitées, mais souvent encore utiles.

# Direkt mit gdb starten (nur in gesicherter Umgebung)
coredumpctl debug PID
# Alternativ: Core und Executable exportieren
coredumpctl dump PID --output=core.pid
file /usr/bin/meinservice
gdb /usr/bin/meinservice core.pid

Symboles de débogage : installez les paquets -dbg/-debuginfo spécifiques au paquet sur une « VM d’analyse » ou utilisez un serveur de symboles. Évitez des installations de débogage larges sur les nœuds de production pour des raisons de mémoire et de sécurité.

Restrictions de sécurité et effets des namespaces

Les paramètres d’unité tels que ProtectSystem=, PrivateTmp=, NoNewPrivileges= ou Capability-Revoke peuvent refuser l’accès aux services même si les dépendances sont satisfaites. Ces options de durcissement sont importantes pour la sécurité, mais peuvent provoquer des dysfonctionnements inattendus.

# Prüfen, ob Härtung gesetzt ist
systemctl show meinservice.service -p ProtectSystem -p PrivateTmp -p NoNewPrivileges -p CapabilityBoundingSet
# SELinux-Denies prüfen (falls aktiv)
ausearch -m AVC -ts recent || true
# AppArmor-Denies prüfen
dmesg | grep apparmor || true

Si un démon d’audit signale des problèmes d’accès, consultez les logs d’audit avant d’assouplir les options de durcissement.

Wants, Requires, BindsTo : règles pour des modèles cohérents

Quand choisir quel comportement ? En bref :

• Wants= : liaison souple, tente de démarrer, tolère les erreurs de la dépendance.
• Requires= : liaison stricte, échoue ou s’arrête en cas d’erreurs de la dépendance.
• BindsTo= : comme Requires, mais l’unité est en outre arrêtée si la dépendance disparaît (p. ex. périphérique retiré).

Exemple : si votre service dépend d’une base de données, choisissez Wants=database.service + After=database.service pour un comportement souple avec des timeouts contrôlés ; choisissez Requires= si le démarrage sans DB entraîne des erreurs critiques.

# Drop-in: /etc/systemd/system/meinservice.service.d/override.conf
[Unit]
Wants=postgresql.service
After=postgresql.service
# Alternativ für harte Abhängigkeit
# Requires=postgresql.service
# After=postgresql.service

Canary deployment et stratégie de rollback pour les modifications d’unité

Les overrides systemd sont puissants ; traitez-les comme du code :

1. Versionnez les drop-ins dans Git et documentez la modification.
2. Appliquez les modifications d’abord sur une instance unique (canary).
3. Test automatisé : vérification du démarrage, contrôle de santé (port, endpoint), tests de fumée.

# Canary: Änderung anwenden und prüfen
systemctl edit meinservice.service   # erstellt Drop-in
systemctl daemon-reload
systemctl RESTart meinservice.service
# Smoke-Test
ss -lnt | grep 12345
curl -f http://127.0.0.1:12345/health || echo "Healthcheck failed"
# Rollback
rm /etc/systemd/system/meinservice.service.d/override.conf
systemctl daemon-reload
systemctl RESTart meinservice.service

Checklist pratique pour les opérateurs d’hébergement

• Collectez initialement status, list-jobs, dependency-Graph et les extraits pertinents du journal.
• Vérifiez les montages, la reachabilité DNS/backend et les ports avant de modifier des units.
• Limitez les installations de debug aux machines d’analyse, pas en production.
• Versionnez les drop-ins et testez régulièrement les rollbacks en staging.
• Mettez en place un forward centralisé des logs pour éviter la perte des journaux de boot et du kernel.

Runbook : séquence d’actions pour un incident

1. Sauvegarder l’état : collecter status, jobs, logs.
2. Déterminer la classe d’erreur : bloqué, fonctionne sans fournir de service, plante.
3. Identifier les dépendances : list-dependencies + critical-chain.
4. Vérifier les bloqueurs : journal de l’unit bloquante, état des montages/réseau/sockets.
5. Examiner le chemin de crash : coredumpctl info, journaux du kernel pour OOM.
6. Vérifier la configuration : systemctl cat, vérifier les drop-ins.
7. Redémarrage contrôlé pour tester l’hypothèse ; puis sauvegarder les logs.

# Schnell-Check-Skript (kompakt)
systemctl status --no-pager --full meinservice.service
systemctl list-dependencies --all meinservice.service
systemd-analyze critical-chain
journalctl -u meinservice.service -b --no-pager -n 200
coredumpctl --no-pager list meinservice.service || true
systemctl cat meinservice.service

Rollback, Rescue und Worst-Case-Szenarien

Si un override aggrave la situation, supprimez le drop-in et rechargez systemd. Testez régulièrement les étapes de rollback. Dans le pire des cas, démarrez en rescue mode, montez la partition système et supprimez manuellement les drop-ins problématiques.

# Drop-in entfernen und Rollback
rm -f /etc/systemd/system/meinservice.service.d/override.conf
systemctl daemon-reload
systemctl RESTart meinservice.service
systemctl status --no-pager --full meinservice.service

Conclusion

Déboguer les dépendances de services systemd signifie lire les chaînes plutôt que de se contenter de redémarrer des services. Avec une séquence de vérification fixe — contrôler l’état, analyser le graphe des dépendances, identifier jobs/bloqueurs, évaluer les logs et les core dumps — vous identifierez la cause racine plus rapidement et effectuerez des modifications de manière sûre et réversible. Pour les environnements d’hébergement, cette méthode réduit les temps d’incident et minimise les effets secondaires tels que la perte de données due à des montages incorrects ou des blocages au démarrage. Maintenez la version des drop-ins, des rollbacks documentés et une stratégie de canary structurée afin que les changements puissent être déployés de façon contrôlée et sûre.

Déboguer les dépendances de services systemd : architecture opérationnelle, aspects Fleet et d’intégration

Au-delà du débogage sur nœud isolé, il existe un ensemble d’aspects architecturaux et opérationnels qui peuvent prévenir des incidents ou entraîner des dépendances inattendues lors d’évolutions. Les décideurs et la direction IT devraient intégrer ces points dans les parcours de déploiement et d’observabilité, afin que le débogage s’effectue au niveau de l’infrastructure plutôt qu’au niveau du traitement des symptômes.

Aspects importants :

• Unit-Quelle und Paketverwaltung: systemd lädt Unit-Dateien aus /lib/systemd/system (Vendor) und /etc/systemd/system (Admin). Verwenden Sie systemd-delta, um überschriebene Einträge zu erkennen und Überraschungen nach Paket-Updates zu vermeiden.
• Enable/Mask-Strategie: Setzen Sie nicht-produktive Units gezielt auf masked, um automatische Starts zu verhindern. Prüfen Sie in CI, ob Deployments Units enabled/disabled hinterlassen.
• Transient Units und Simulationen: Für Testläufe nutzen Sie systemd-run oder transient units in einer isolierten Testumgebung, bevor Sie Änderungen in der gesamten Flotte ausrollen.
• Konfigurationsdrift und Automatisierung: Versionieren Sie Unit-Änderungen im Konfig-Repo und validieren Sie Unit-Syntax automatisiert (systemd-analyze verify) als Teil des Release-Pipelines. So vermeiden Sie unterschiedliche Dependency-Modelle zwischen Staging und Produktion.
• Observability und Alerting: Modellieren Sie Health-Checks, die nicht nur Prozess-Liveness, sondern Anwendungs-Health (z. B. DB-Verbindung) prüfen. Erstellen Sie Alerts für StartLimitHit, wiederholte RESTart-Loops und erhöhte journald-Disk-Usage, damit Probleme frühzeitig erkennbar sind.
• Datenschutz und Coredumps: Core Dumps können vertrauliche Daten enthalten. Definieren Sie Policies, wo Dumps gespeichert und wer Zugriff hat; nutzen Sie eine Analyse-VM mit Symbolserver statt breitflächiger Debug-Installationen auf Produktivsystemen.

Risiken bei Änderungen: package-Updates können Units überschreiben, Masking/unabsichtliche Enables führen zu Startzyklen, und inkonsistente network-online-Implementierungen erzeugen intermittierende Boot-Blockaden. Betreiben Sie daher Unit-Checks als Teil des Release-Prozesses und führen Sie Canary-Rollouts mit gezielten Inventar-Tags durch. So verbinden Sie systemd-Fehlerdiagnose mit nachhaltiger Betriebssteuerung und vermeiden wiederkehrende Abhängigkeitsvorfälle in Ihrer Hosting-Umgebung.

Für dieses Thema sind auch Systemd Abhängigkeiten wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.