Comprendre systemdle gestionnaire de système Linux

systemd
Administration système Linux systemd

01 Qu’est-ce que systemd ?

systemd est le gestionnaire de système et de services devenu standard sur la quasi-totalité des distributions Linux majeures (Debian, Ubuntu, Fedora, Arch, openSUSE…). Développé par Lennart Poettering en 2010, il remplace les anciens systèmes d’init tels que SysVinit et Upstart.

Son rôle fondamental est d’être le premier processus lancé par le noyau (PID 1). Il prend en charge l’intégralité de la séquence de démarrage puis supervise les services jusqu’à l’extinction.

Noyau Linux (kernel) systemd — PID 1 Premier processus du système journald networkd logind udevd resolved SysVinit — séquentiel script 1 script 2 script 3 Lent — un script à la fois systemd — parallèle nginx sshd mysql cron udev dbus network logind Rapide — démarrage en parallèle

02 Architecture et composants

systemd est une suite de démons et utilitaires qui collaborent via D-Bus. Tous partagent un modèle de données unifié pilotable depuis systemctl.

Suite systemd systemctl CLI de contrôle journald Centralise les logs networkd Réseau bas niveau resolved DNS avec cache logind Sessions udevd Périphériques timedatectl Horloge / TZ tmpfiles Fichiers temp

03 Les units systemd

La brique fondamentale de systemd est l’unit. Chaque unit est un fichier déclaratif qui décrit une ressource à gérer.

.service Daemon .timer Planification .socket Activation .mount Montage FS .target Groupement .path Evén. fichier

Emplacements des fichiers unit

Priorité haute /etc/systemd/system/ Personnalisations admin Priorité basse /lib/systemd/system/ Fournies par les paquets écrase
Bonne pratique

Ne jamais modifier les fichiers dans /lib/systemd/system/. Utiliser systemctl edit nom.service pour créer un override dans /etc/systemd/system/, préservé lors des mises à jour.

04 Commandes systemctl essentielles

inactive activating active failed start ready crash stop restart

Référence rapide systemctl


# Démarrer / arrêter / redémarrer
systemctl start   nginx
systemctl stop    nginx
systemctl restart nginx
systemctl reload  nginx      # rechargement config sans coupure

# Activer au démarrage
systemctl enable  --now nginx   # enable + start en une commande
systemctl disable nginx

# Inspecter
systemctl status  nginx
systemctl list-units --type=service --state=running
systemctl list-units --state=failed

# Après modification d'un fichier unit
systemctl daemon-reload

# Analyser le temps de démarrage
systemd-analyze blame

05 Créer un service personnalisé

monapp.service [Unit] Description=Mon application After=network.target [Service] Type=simple User=www-data ExecStart=/opt/monapp/monapp Restart=on-failure [Install] WantedBy=multi-user.target Dépendances et ordre de démarrage Commande, utilisateur, politique de redémarrage et ressources allouées Target d’activation (enable)

# Activer le nouveau service
systemctl daemon-reload
systemctl enable --now monapp
systemctl status monapp

06 Targets et niveaux d’exécution

Les targets remplacent les runlevels SysVinit. Elles regroupent des services pour atteindre un état système précis.

poweroff RL 0 rescue RL 1 multi-user RL 2–4 · réseau · sans GUI graphical RL 5 · interface graphique reboot RL 6 emergency

systemctl get-default               # target active
systemctl set-default multi-user.target
systemctl isolate rescue.target     # bascule immédiate

07 journald et consultation des logs

kernel services journald /run/log/journal binaire /var/log/journal/ journalctl lecture / filtres

journalctl -f                        # suivi temps réel
journalctl -u nginx -f               # service spécifique
journalctl -b                        # depuis le dernier boot
journalctl -p err                    # erreurs uniquement
journalctl --since "1 hour ago"
journalctl --vacuum-size=500M        # rotation manuelle

08 Timers systemd — l’alternative à cron

sauvegarde .timer déclenche sauvegarde .service Avantages vs cron : ✔ Logs dans journald ✔ Rattrapé si machine était éteinte ✔ Supervision systemd native

[Timer]
OnCalendar=*-*-* 02:30:00   # tous les jours à 2h30
Persistent=true             # rattrape les exécutions manquées
RandomizedDelaySec=300      # décalage aléatoire 0-5 min

[Install]
WantedBy=timers.target

systemctl list-timers --all         # tous les timers actifs
systemd-analyze calendar "weekly"  # vérifie la syntaxe

09 Sécurité et sandboxing

systemd offre des directives de sandboxing sans recourir à des conteneurs, directement dans la section [Service].

Sandboxing systemd [Service] Système de fichiers ProtectSystem=strict ProtectHome=yes PrivateTmp=yes ReadWritePaths= Réseau & utilisateur PrivateNetwork=yes PrivateUsers=yes NoNewPrivileges=yes Syscalls SystemCallFilter= @system-service CapabilityBounding Set=CAP_NET_BIND Ressources MemoryMax=512M CPUQuota=50% TasksMax=100
Outil de diagnostic

systemd-analyze security nom.service attribue un score de sécurité et liste les directives manquantes. Le point de départ idéal pour durcir un service.

10 Conclusion

systemd est aujourd’hui incontournable pour tout administrateur Linux. Sa maîtrise permet de créer des services robustes, de centraliser les logs, de planifier des tâches de façon fiable et de durcir la sécurité sans infrastructure conteneur.

La documentation officielle (man systemd.service, man systemd.timer) reste la référence exhaustive.