⚙️ systemd – Init, Service Management & journald

Qu'est-ce que systemd ?

systemd est le "System and Service Manager" (Gestionnaire de Système et de Services) pour Linux. C'est le système d'init moderne.

C'est le premier processus lancé par le Noyau (Kernel) au démarrage. Il a le PID 1 (Process ID 1).

Son Rôle (PID 1)

En tant que PID 1, systemd est le "père" (ou "ancêtre") de tous les autres processus (services) du système.

• Démarrage (Boot) : Il est responsable du démarrage (lancement) de tous les services nécessaires (Réseau, SSHD, Nginx, Cron...) au boot, en parallèle (rapide).
• Gestion (Runtime) : Il surveille (monitor) tous ces services. Si nginx crash, c'est systemd (via Restart=) qui le redémarre.
• Arrêt (Shutdown) : Il gère l'arrêt propre de tous les services.

systemd (2010+) remplace le système SysVinit (init) (1980s).

systemd n'est pas un seul binaire, c'est une suite (stack) de daemons et d'outils (ce qui lui est reproché).

Une Unit (Unité) est l'objet de base que systemd gère. C'est un simple fichier .ini (texte) qui décrit une ressource.

Types d'Unit (Suffixes)

Emplacements (Priorité)

• /lib/systemd/system/ : (Bas) Installé par les paquets (apt, dnf). (Ne pas modifier).
• /run/systemd/system/ : (Moyen) Généré au Runtime.
• /etc/systemd/system/ : (Haut) Prioritaire. Là où l'admin crée ses propres units (.service) ou ses "overrides" (surcharges).

Un fichier "Unit" (ex: myapp.service) est un fichier .ini structuré en 3 sections principales.

# Fichier: /etc/systemd/system/myapp.service

# --- 1. Métadonnées & Dépendances ---
[Unit]
Description=Mon Application Web (Gunicorn)
After=network.target mysql.service
Wants=mysql.service

# --- 2. Logique d'Exécution ---
[Service]
Type=simple
User=www-data
Group=www-data
WorkingDirectory=/srv/myapp
ExecStart=/srv/myenv/bin/gunicorn --workers 4 myapp:app
Restart=on-failure
RestartSec=5
Environment="MODE=prod"

# --- 3. Démarrage (Boot) ---
[Install]
WantedBy=multi-user.target

• [Unit] : (Métadonnées) Description, et Dépendances (Ordre de démarrage).
• [Service] : (Le "Comment") La commande à exécuter, l'utilisateur, le redémarrage.
• [Install] : (Activation) À quel "Runlevel" (Target) ce service doit-il être attaché (via systemctl enable).

La section [Unit] gère les métadonnées et, surtout, l'ordre de démarrage (remplace les S10, S20 de SysVinit).

Exemple (Le plus courant)

[Unit]
Description=Mon App
# (Attend que le réseau (network.target)
#  et que la BDD (mysql.service) soient UP
#  avant de se lancer)
After=network.target mysql.service

# (Tente de démarrer mysql.service en parallèle,
#  mais ne plantera pas si mysql échoue)
Wants=mysql.service

La section [Service] définit comment exécuter le processus. C'est la plus importante pour un service.

La section [Install] ne fait rien au runtime. Elle n'est utilisée que par la commande systemctl enable (et disable).

WantedBy= (Lien)

Cette directive (la seule importante ici) dit à systemd : "Si l'utilisateur 'enable' ce service, à quel Target (Runlevel) doit-il être rattaché ?"

[Install]
# (Ce service doit être démarré quand le système
#  entre dans l'état "multi-user" (Runlevel 3/5))
WantedBy=multi-user.target

Flux (systemctl enable myapp.service)

1. systemd lit /etc/systemd/system/myapp.service.
2. Il voit WantedBy=multi-user.target.
3. Il crée un lien symbolique (symlink) :
   ln -s /etc/systemd/system/myapp.service /etc/systemd/system/multi-user.target.wants/myapp.service

(Au prochain boot, quand multi-user.target démarre, systemd démarre tout ce qui se trouve dans son dossier .wants/).

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

# Redémarrer un service (Stop puis Start)
$ sudo systemctl restart nginx

# Recharger la configuration (SIGHUP) (si 'ExecReload' est défini)
# (Ne tue pas le processus, ex: Nginx)
$ sudo systemctl reload nginx

# Tenter un 'reload', sinon 'restart'
$ sudo systemctl reload-or-restart nginx

Commandes systemctl pour gérer si un service doit se lancer au démarrage (boot).

# Activer (au prochain boot)
# (Crée le symlink 'WantedBy' (voir 3.3))
$ sudo systemctl enable nginx

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

# Désactiver (au prochain boot)
# (Supprime le symlink)
$ sudo systemctl disable nginx

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

# Empêche le service de démarrer (manuellement OU par dépendance)
$ sudo systemctl mask nginx

# (Le service est maintenant "mort" jusqu'à l'unmask)

# Autoriser à nouveau
$ sudo systemctl unmask nginx

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.

Commandes de Filtrage (Les plus utiles)

# 1. Voir TOUT (le plus récent en bas) (Pipe vers 'less' auto)
$ journalctl

# 2. (Le plus utile) Suivre (tail -f) les logs
$ journalctl -f

# 3. Filtrer par Service (Unit)
$ journalctl -u nginx.service
# (Suivre les logs Nginx)
$ journalctl -f -u nginx.service

# 4. Filtrer par Temps
$ journalctl -S "1 hour ago"  # (Depuis 1h)
$ journalctl -S today
$ journalctl -S "2025-11-10 14:00:00" -U "2025-11-10 14:05:00"

# 5. Filtrer par Priorité (Gravité)
# (p=3 -> 'err')
$ journalctl -p err
# (p=4 -> 'warning')
$ journalctl -p warning

# 6. Combiner (Logs d'erreur Nginx de la dernière heure)
$ journalctl -u nginx.service -p err -S "1 hour ago"

# 7. (Dmesg) Voir les logs Kernel
$ journalctl -k

Où sont stockés les logs ? (/etc/systemd/journald.conf).

# Fichier: /etc/systemd/journald.conf

[Journal]
# (Storage=persistent)

# (Taille max pour /var/log/journal)
SystemMaxUse=4G

# (Garder 10% de l'espace disque libre)
SystemKeepFree=10%

# (Taille max pour /run/log/journal (RAM))
RuntimeMaxUse=500M

Les .timer sont l'alternative (le "remplaçant") moderne de cron (voir guide Cron). Ils sont plus puissants et mieux intégrés.

La section [Timer] du fichier .timer définit le "Quand".

Types de Timers

• Monotoniques (Après le boot) :
  • OnBootSec= : (ex: OnBootSec=5min) (5 min *après* le boot).
  • OnUnitActiveSec= : (ex: 30s) (30 sec *après* l'activation de ce timer). (Pour les "timers" récurrents, type @hourly).
• Temps Réel (Calendrier) :
  • OnCalendar= : (Le plus puissant, remplace la syntaxe cron).

Syntaxe OnCalendar=

# (Similaire à cron, mais plus lisible)
# (Format: JourSem YYYY-MM-DD HH:MM:SS)

# Tous les jours à 2h00
OnCalendar=daily
# (ou)
OnCalendar=02:00:00

# Tous les 15 minutes (toute la journée)
OnCalendar=*:0/15

# Toutes les heures, aux minutes 0 et 30
OnCalendar=*:0,30

# Tous les Lundis à 9h00 (heures de bureau)
OnCalendar=Mon *-*-* 09:00:00

# Le 1er et le 15 du mois, à 4h00
OnCalendar=*-*-01,15 04:00:00

Un "timer" systemd nécessite deux fichiers "Unit", qui doivent avoir le même nom (ex: backup.timer et backup.service).

# Fichier: /etc/systemd/system/backup.service

[Unit]
Description=Exécuter le script de backup

[Service]
Type=oneshot
User=root
ExecStart=/usr/local/bin/backup.sh

# Fichier: /etc/systemd/system/backup.timer

[Unit]
Description=Timer pour le backup (2h du matin)

[Timer]
# (Exécuter tous les jours à 2h00)
OnCalendar=daily
# (ou OnCalendar=02:00:00)

# (Si le PC était éteint,
#  exécute au boot si manqué)
Persistent=true

[Install]
WantedBy=timers.target

3. Activation

On active et démarre uniquement le .timer (pas le .service).

# Activer le timer (au boot)
$ sudo systemctl enable backup.timer

# Démarrer le timer (maintenant)
$ sudo systemctl start backup.timer

# Lister tous les timers actifs
$ systemctl list-timers

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

Une "Target" est un point de synchronisation (un "groupe" de services) qui définit l'état du système.

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

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

# Changer (maintenant)
$ sudo systemctl isolate multi-user.target

systemd fournit une suite d'outils CLI (Clients) pour gérer les daemons (Serveurs) correspondants.

hostnamectl

(Gère systemd-hostnamed)

# Voir le statut (hostname, OS, Kernel...)
$ hostnamectl

# Changer le nom d'hôte (hostname)
$ sudo hostnamectl set-hostname "nouveau-serveur"

timedatectl

(Gère systemd-timedated)

# Voir le statut (Heure, Timezone, NTP)
$ timedatectl
Local time: Wed 2025-11-12 10:00:00 CET
...
Time zone: Europe/Paris (CET, +0100)
System clock synchronized: yes
NTP service: active

# Lister les Timezones
$ timedatectl list-timezones

# Changer la Timezone
$ sudo timedatectl set-timezone "Europe/London"

# Activer la synchro NTP
$ sudo timedatectl set-ntp true