Les services et systemd

Sur un serveur Linux, les programmes qui tournent en permanence (serveur web, base de données, agent de supervision, et même le kubelet de Kubernetes) sont des services. Sur presque toutes les distributions actuelles, c'est systemd qui les démarre, les surveille, les redémarre en cas de panne et collecte leurs journaux. Cette leçon est théorique : votre machine de lab, un conteneur sans privilèges, n'a pas de systemd.

Ce que vous saurez à la fin : piloter un service avec systemctl, lire ses journaux avec journalctl, comprendre un fichier d'unité et savoir comment se déroule le démarrage d'une machine.

1. Le démarrage d'une machine, en bref

firmware (UEFI/BIOS) → chargeur d'amorçage (GRUB) → noyau Linux → systemd (PID 1) → services

systemd est le premier processus (PID 1) : il démarre tous les autres, dans l'ordre de leurs dépendances, en parallèle quand c'est possible.

2. Piloter un service : systemctl

systemctl status nginx          # état, PID, dernières lignes de journal
sudo systemctl start nginx      # démarrer maintenant
sudo systemctl stop nginx       # arrêter
sudo systemctl restart nginx    # arrêter puis démarrer
sudo systemctl reload nginx     # relire la configuration sans couper (si le service le permet)
sudo systemctl enable nginx     # démarrer automatiquement au prochain boot
sudo systemctl disable nginx    # ne plus le démarrer au boot
systemctl list-units --type=service --failed   # les services en échec

Piège classique : start n'implique pas enable. Un service démarré à la main mais pas activé ne revient pas après un redémarrage. systemctl enable --now nginx fait les deux.

3. Lire les journaux : journalctl

journalctl -u nginx              # tous les journaux du service nginx
journalctl -u nginx -f           # en direct, comme tail -f
journalctl -u nginx --since "1 hour ago"
journalctl -p err -b             # les erreurs depuis le dernier démarrage

4. Un fichier d'unité

Chaque service est décrit par une unité, un petit fichier texte (/etc/systemd/system/monapp.service pour les vôtres) :

[Unit]
Description=Mon application
After=network-online.target      # démarrer après le réseau

[Service]
ExecStart=/usr/local/bin/monapp --port 8080
User=monapp                      # jamais root si ce n'est pas nécessaire
Restart=on-failure               # redémarrer en cas de plantage
RestartSec=5
Environment=ENV=production

[Install]
WantedBy=multi-user.target       # « activé » = démarré avec le système

Après toute modification d'un fichier d'unité : sudo systemctl daemon-reload, puis restart.

5. Les autres types d'unités

Type	Rôle
.service	un programme
.timer	une tâche planifiée (l'équivalent moderne de cron)
.socket	démarre un service à la première connexion
.target	un groupe d'unités (un « niveau » de démarrage, comme multi-user.target)
.mount	un point de montage

6. Et dans un conteneur ?

Un conteneur exécute en général un seul processus, sans systemd : c'est l'orchestrateur qui joue le rôle de superviseur. Le tableau de correspondance est instructif :

systemd	Kubernetes
Restart=on-failure	restartPolicy du pod
systemctl status / journalctl -u	kubectl describe pod / kubectl logs
enable (démarrer au boot)	un Deployment qui maintient le pod en vie
.timer	CronJob

Sur les nœuds d'un cluster, en revanche, systemd reste là : il démarre le moteur de conteneurs et le kubelet. Diagnostiquer un nœud NotReady, c'est souvent systemctl status kubelet et journalctl -u kubelet.

Validez la leçon avec le questionnaire.