# 2. systemd et la gestion de services

systemd est le système d'init de la quasi-totalité des distributions Linux
majeures depuis le milieu des années 2010 (PID 1, premier processus lancé
par le noyau). Cette section couvre les unités, l'ordonnancement des
dépendances au démarrage, la journalisation, et les nouveautés récentes
(version 261, juin 2026).

## Les unités — bien plus que des services

Une **unité** systemd est un fichier déclaratif décrivant une ressource
gérée. Les types les plus courants :

- **`.service`** : un processus à démarrer/arrêter/superviser.
- **`.socket`** : un socket réseau ou Unix — permet le *socket activation*,
  démarrer le service correspondant seulement à la première connexion reçue.
- **`.timer`** : un déclencheur temporel, alternative moderne à cron
  (détaillée en section 12).
- **`.mount`** / **`.automount`** : un point de montage géré déclarativement,
  avec montage à la demande pour `.automount`.
- **`.target`** : un point de synchronisation regroupant d'autres unités
  (ex. `multi-user.target`), sans processus propre — l'équivalent moderne
  des anciens *runlevels*.
- **`.slice`** : un nœud de la hiérarchie cgroup (voir section 1), pour
  regrouper et limiter collectivement plusieurs unités.

## Dépendances déclaratives, pas un ordre figé

Contrairement à un script d'init séquentiel, systemd résout un **graphe de
dépendances** et démarre en parallèle tout ce qui peut l'être. Directives
clés d'une section `[Unit]` :

- `Requires=` : dépendance forte — l'échec de la cible entraîne l'arrêt de
  l'unité dépendante.
- `Wants=` : dépendance faible — un échec de la cible n'empêche pas le
  démarrage.
- `After=` / `Before=` : ordre relatif pur, **sans** impliquer de dépendance
  de démarrage (`After=` seul ne garantit pas que l'unité cible soit lancée,
  seulement que si les deux démarrent, l'ordre est respecté) — piège
  fréquent chez les débutants : `Requires=`/`Wants=` et `After=`/`Before=`
  sont deux axes indépendants, presque toujours combinés ensemble.

## Cycle de vie et supervision

Chaque service peut déclarer un `Type=` (`simple`, `forking`, `oneshot`,
`notify`, `dbus`) qui indique à systemd **comment savoir** que le service a
fini de démarrer. `Restart=on-failure` (avec `RestartSec=`) fournit une
supervision automatique — le patron classique de haute disponibilité au
niveau d'un seul service. `systemd-cgls`/`systemd-cgtop` affichent
respectivement la hiérarchie et la consommation en temps réel par cgroup.

## journald — la journalisation structurée

journald collecte stdout/stderr de chaque unité (plus les messages du
noyau et les appels `syslog()` classiques) dans un format **binaire indexé**
(pas du texte brut) rotatif, interrogeable avec `journalctl` :

- `journalctl -u nom.service` : uniquement cette unité.
- `journalctl -b` : depuis le dernier démarrage.
- `journalctl -f` : suivi en continu (équivalent `tail -f`).
- `journalctl -p err` : filtrage par niveau de sévérité syslog.

Chaque entrée porte des métadonnées structurées (PID, UID, cgroup
d'origine, horodatage monotone ET horloge murale) — un simple grep sur un
fichier texte ne peut pas reconstituer ces champs après coup.

## Nouveautés récentes (259 à 261, 2026)

- **systemd 259** a retiré le support historique des scripts SysV
  (`/etc/init.d/`) — toute unité doit désormais être une unité native.
- **systemd 260** a ajouté des garde-fous explicites contre les agents
  automatisés qui tenteraient de modifier la configuration système sans
  supervision humaine — reflet direct des nouveaux usages d'assistants IA
  dans l'administration système.
- **systemd 261** (juin 2026) introduit un service de **TPM logiciel**
  (`systemd-tpm2`, utile en environnement virtualisé sans TPM matériel — lié
  au chiffrement de disque, voir section 6), un sous-système de métadonnées
  cloud (`systemd-imdsd`), et **`systemd-sysinstall`**, un nouvel installeur
  textuel piloté par une configuration déclarative plutôt qu'un script
  shell ad hoc.

*(Schéma disponible : `schema.svg`, dans ce dossier.)*