⚙️ systemctl & journalctl – Gestion de Services & Logs

systemd est le daemon (PID 1) qui gère le système.

systemctl (System Control) est l'outil en ligne de commande (CLI) que vous (l'administrateur) utilisez pour parler au daemon systemd.

systemctl est votre "télécommande" principale pour :

• Gérer les services (Start, Stop, Restart).
• Gérer le démarrage (Enable, Disable).
• Vérifier l'état (Status).
• Contrôler le système (Reboot, Poweroff).

Commandes systemctl pour gérer un service maintenant (session actuelle).

# Démarrer un service
$ sudo systemctl start nginx.service
# ('.service' est optionnel)
$ sudo systemctl start nginx

# Arrêter un service
$ sudo systemctl stop nginx

# Vérifier s'il est actif (running)
$ systemctl status nginx

C'est une distinction cruciale pour la production.

$ sudo systemctl restart nginx

$ sudo systemctl reload nginx

enable (Activer) est la commande qui "accroche" (hook) un service au démarrage (boot).

Fonctionnement (Symlink)

systemctl enable nginx ne démarre pas le service.

Il lit la section [Install] du fichier nginx.service (ex: WantedBy=multi-user.target) et crée un lien symbolique (symlink) pour "l'accrocher" à cette "cible" (target) de boot.

# Activer (au prochain boot)
$ sudo systemctl enable nginx
Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /lib/systemd/system/nginx.service.

# Activer ET Démarrer (maintenant)
$ sudo systemctl enable --now nginx

disable (Désactiver) est l'inverse de enable. Il supprime le lien symbolique (symlink) WantedBy=.

Le service ne démarrera plus au prochain boot.

Attention : disable n'arrête pas (stop) le service s'il est déjà en cours d'exécution.

# Désactiver (au prochain boot)
$ sudo systemctl disable nginx
Removed /etc/systemd/system/multi-user.target.wants/nginx.service.

# Désactiver ET Arrêter (maintenant)
$ sudo systemctl disable --now nginx

status est l'outil de diagnostic n°1. Il combine l'état du service et les 10 dernières lignes de journalctl (5.2).

$ systemctl status nginx
● nginx.service - A high performance web server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2025-11-10 10:00:00 CET; 1 day 2h ago
   Main PID: 1234 (nginx)
      Tasks: 4 (limit: 9400)
     Memory: 50.0M
        CPU: 1.5s
     CGroup: /system.slice/nginx.service
             ├─1234 /usr/sbin/nginx -g 'daemon off;'
             └─1235 /usr/sbin/nginx (worker process)

Nov 10 10:00:00 server systemd[1]: Starting A high performance web server...
Nov 10 10:00:01 server systemd[1]: Started A high performance web server.

États (Active)

status est pour les humains. Pour les scripts (Bash), systemctl fournit des commandes (qui retournent un exit code 0 (vrai) ou non-zéro (faux)).

is-active (Statut Runtime)

# (Vérifie si le service est 'active (running)')
$ systemctl is-active nginx
active
$ echo $?
0

$ systemctl is-active apache2
inactive
$ echo $?
3

is-enabled (Statut Boot)

# (Vérifie si le service est 'enabled' au boot)
$ systemctl is-enabled nginx
enabled
$ echo $?
0

is-failed (Statut Erreur)

# (Vérifie si le service est en état 'failed')
$ systemctl is-failed nginx
active

list-units (Runtime)

Liste les unités chargées en mémoire (actives, inactives, failed).

# Lister tous les services (actifs ou non)
$ systemctl list-units --type=service --all

# Lister les services 'running'
$ systemctl list-units --type=service --state=running

# Lister les services 'failed'
$ systemctl list-units --type=service --state=failed

list-unit-files (Boot)

Liste tous les fichiers "Unit" installés sur le disque, et leur statut "boot".

$ systemctl list-unit-files --type=service
UNIT FILE        STATE
nginx.service    enabled
ssh.service      enabled
ufw.service      disabled
...
cron.service     masked

Le Piège : Vous avez modifié un fichier .service (ex: /etc/systemd/system/myapp.service) pour changer le ExecStart.

Vous lancez sudo systemctl restart myapp. Le changement n'est pas pris en compte !

La Solution

systemd (PID 1) charge en RAM (cache) les fichiers .service au boot. Il ne surveille pas les changements sur le disque.

Vous devez lui dire de "re-scanner" (re-lire) les fichiers de configuration sur le disque.

Workflow (Modification de .service)

# 1. (Modifier /etc/systemd/system/myapp.service)

# 2. (Dire à systemd de relire les fichiers)
$ sudo systemctl daemon-reload

# 3. (Maintenant, redémarrer le service
#     pour appliquer le nouveau 'ExecStart')
$ sudo systemctl restart myapp

Problème : Ne jamais modifier directement un fichier "système" (ex: /lib/systemd/system/nginx.service). Il sera écrasé lors de la prochaine apt upgrade.

Solution : Override (Surcharge)

La commande systemctl edit est la méthode "propre" pour surcharger (override) les directives.

# Ouvre un éditeur (nano/vim)
$ sudo systemctl edit nginx.service

Cela crée un fichier "override" (ex: /etc/systemd/system/nginx.service.d/override.conf).

# Dans l'éditeur, ajoutez SEULEMENT
# ce que vous voulez changer :

[Service]
# (Surcharger une directive)
Restart=always
# (Ajouter une directive)
RestartSec=10
# (Vider une directive)
Environment=

Résultat : systemd "fusionne" (merge) l'original (/lib/...) et l'override (/etc/...) en mémoire.

Les .target (Cibles) sont le remplacement (moderne) des "Runlevels" (Niveaux d'exécution) de SysVinit.

# Voir la target (runlevel) par défaut
$ systemctl get-default
graphical.target

# Changer la target (runlevel) par défaut
# (ex: passer en mode serveur CLI par défaut)
$ sudo systemctl set-default multi-user.target

# Changer de target (maintenant)
# (Tue la GUI et passe en mode CLI)
$ sudo systemctl isolate multi-user.target

# (Redémarre la GUI)
$ sudo systemctl isolate graphical.target

systemd-journald est le service (daemon) de logging de systemd. Il vise à remplacer (ou centraliser) rsyslog.

Le "Journal"

journald capture et centralise tous les logs :

• Logs Kernel : (dmesg)
• Logs Syslog : (Écoute sur /dev/log, remplace rsyslog)
• Logs stdout/stderr : (Le plus important) Capture automatiquement toutes les sorties (echo, print) de tous les services gérés par systemd.

Stockage (Binaire/Structuré)

Contrairement à Syslog (/var/log/syslog) qui est 100% texte, journald stocke les logs dans un format binaire, structuré (JSON-like) et indexé.

Avantage : Permet des requêtes (journalctl) extrêmement rapides et un filtrage puissant (ex: "Montre-moi les logs du service nginx, niveau error, de la session 5").

journalctl est l'outil (CLI) pour lire le journal binaire de journald.

# 1. Voir TOUT (le plus récent en bas)
# (Utilise 'less' (paginé) par défaut)
$ journalctl

# 2. (Le plus utile) Suivre (tail -f) les logs en temps réel
$ journalctl -f

# 3. Afficher les N dernières lignes (ex: 100)
$ journalctl -n 100

# 4. (Suivre + 100 dernières lignes)
$ journalctl -f -n 100

# 5. (Ne pas paginer, 'cat' le tout)
$ journalctl --no-pager

C'est le filtre le plus important. Il n'affiche que les logs (stdout, stderr) générés par une Unit (service) spécifique.

# Afficher tous les logs (historiques) de Nginx
$ journalctl -u nginx.service
# (ou '$ journalctl -u nginx')

# Suivre (tail -f) les logs de Nginx
$ journalctl -f -u nginx

# Suivre les logs de 2 services en même temps
$ journalctl -f -u nginx -u php-fpm

# Afficher les logs d'un Timer
$ journalctl -u backup.timer
$ journalctl -u backup.service

Filtrage par date/heure.

-S (Since) (Depuis)

# Depuis "aujourd'hui" (00:00)
$ journalctl -S today

# Depuis "hier"
$ journalctl -S yesterday

# Depuis 1 heure
$ journalctl -S "1 hour ago"

# Depuis une date/heure spécifique
$ journalctl -S "2025-11-10 14:00:00"

-U (Until) (Jusqu'à)

# (Combiné) Logs de 14h00 à 14h05
$ journalctl -S "2025-11-10 14:00:00" -U "2025-11-10 14:05:00"

Filtre les logs par niveau de priorité (Syslog) (0-7).

# Afficher les erreurs (err, 3) et pire (crit, alert, emerg)
$ journalctl -p err
# (ou)
$ journalctl -p 3

# Afficher les warnings (4) et pire
$ journalctl -p warning

# Afficher le niveau 'info' (6) et pire
$ journalctl -p info

Combinaison (Diagnostic)

# (Le "Top" du diagnostic)
# "Montre-moi les erreurs (et pire)
#  du service 'nginx', depuis hier"

$ journalctl -u nginx -p err -S yesterday

L'option -k (ou --dmesg) filtre le journal pour n'afficher que les messages du Noyau (Kernel).

C'est le remplaçant moderne de la commande dmesg.

Usage (Diagnostic Matériel/Driver)

# Afficher les logs du Kernel (paginé)
$ journalctl -k

# Suivre (tail -f) les logs du Kernel
# (Utile si on branche une clé USB
#  ou si un disque (SATA) a des erreurs I/O)
$ journalctl -k -f