⚙️ Gestion des Services avec systemd
| Formation | BTS SIO option SISR — IRIS Mediaschool |
|---|---|
| Bloc | B2 — Administration Systèmes & Réseaux |
| Module | M2.2 — Administration Linux |
| Prérequis | Maîtrise du shell Linux (C2.2.1) |
🎯 Objectifs
- Comprendre le rôle de systemd dans le démarrage et la gestion des services Linux
- Maîtriser les commandes
systemctlpour administrer les services - Savoir créer et personnaliser un fichier
.service - Utiliser
journalctlpour consulter et filtrer les logs - Comprendre les targets, les timers et l'ordonnancement des services
📖 systemd : le gestionnaire de démarrage et services
systemd est le système d'initialisation (init system) utilisé par la quasi-totalité des distributions Linux modernes (Debian, Ubuntu, CentOS, Fedora, Arch…). Il remplace les anciens systèmes comme SysVinit et Upstart.
systemd est le premier processus lancé par le noyau Linux au démarrage (PID 1). Il est responsable de :
- L'initialisation du système (montage des systèmes de fichiers, réseau, etc.)
- Le démarrage et l'arrêt des services (démons)
- La gestion des dépendances entre services
- La journalisation centralisée des logs
- La gestion des timers (tâches planifiées)
📖 Les unités systemd
systemd organise tout en unités (units). Chaque unité est définie par un fichier de configuration :
| Type d'unité | Extension | Description |
|---|---|---|
| Service | .service | Gère un processus démon (Apache, Nginx, SSH…) |
| Socket | .socket | Active un service à la demande via un socket réseau/IPC |
| Timer | .timer | Planifie l'exécution d'un service (alternative à cron) |
| Mount | .mount | Gère le montage d'un système de fichiers |
| Target | .target | Regroupe des unités (équivalent des runlevels) |
Les fichiers d'unité sont stockés dans :
/usr/lib/systemd/system/: unités fournies par les paquets (ne pas modifier)/etc/systemd/system/: unités personnalisées ou surcharges (priorité la plus haute)
📖 Commandes systemctl
systemctl est la commande principale pour interagir avec systemd :
| Commande | Description |
|---|---|
systemctl start nginx | Démarrer un service |
systemctl stop nginx | Arrêter un service |
systemctl restart nginx | Redémarrer un service |
systemctl reload nginx | Recharger la configuration sans redémarrage |
systemctl enable nginx | Activer le démarrage automatique au boot |
systemctl disable nginx | Désactiver le démarrage automatique |
systemctl status nginx | Afficher l'état du service (actif, logs récents) |
systemctl is-active nginx | Vérifier si le service est en cours d'exécution |
systemctl is-enabled nginx | Vérifier si le service est activé au boot |
systemctl daemon-reload | Recharger les fichiers d'unité après modification |
systemctl list-units --type=service | Lister tous les services chargés |
Après toute modification d'un fichier .service, exécutez systemctl daemon-reload avant de redémarrer le service. Sans cette commande, systemd utilisera l'ancienne version du fichier.
📖 Anatomie d'un fichier .service
Un fichier service est composé de trois sections principales :
[Unit]
Description=Mon application web personnalisée
Documentation=https://example.com/docs
After=network.target
Requires=postgresql.service
[Service]
Type=simple
User=webapp
Group=webapp
WorkingDirectory=/opt/webapp
ExecStart=/opt/webapp/bin/start.sh
ExecStop=/opt/webapp/bin/stop.sh
Restart=on-failure
RestartSec=5
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target| Section | Directive | Description |
|---|---|---|
| [Unit] | Description | Description lisible du service |
After | Démarrer après cette unité | |
Requires | Dépendance obligatoire | |
| [Service] | Type | Type de service : simple, forking, oneshot, notify |
ExecStart | Commande de démarrage | |
ExecStop | Commande d'arrêt | |
Restart | Politique de redémarrage (always, on-failure, no) | |
User | Utilisateur d'exécution | |
| [Install] | WantedBy | Target dans laquelle activer le service |
📖 Créer un service personnalisé
Exemple complet : créer un service pour une API Node.js :
# 1. Créer le fichier service
sudo nano /etc/systemd/system/mon-api.service
# 2. Contenu du fichier :
[Unit]
Description=API Node.js - Mon Application
After=network.target
[Service]
Type=simple
User=nodeapp
WorkingDirectory=/opt/mon-api
ExecStart=/usr/bin/node /opt/mon-api/server.js
Restart=always
RestartSec=10
Environment=NODE_ENV=production
Environment=PORT=3000
[Install]
WantedBy=multi-user.target
# 3. Recharger, activer et démarrer
sudo systemctl daemon-reload
sudo systemctl enable mon-api
sudo systemctl start mon-api
sudo systemctl status mon-api📖 Journalisation avec journalctl
journalctl est l'outil de consultation des logs centralisés de systemd :
| Commande | Description |
|---|---|
journalctl | Afficher tous les logs |
journalctl -u nginx | Logs d'un service spécifique |
journalctl -u nginx --since "1 hour ago" | Logs depuis une date/durée |
journalctl -u nginx --since today | Logs du jour |
journalctl -p err | Filtrer par priorité (emerg, alert, crit, err, warning, notice, info, debug) |
journalctl -f | Suivre les logs en temps réel (comme tail -f) |
journalctl -b | Logs du dernier démarrage |
journalctl --disk-usage | Espace disque utilisé par les logs |
Combinez les filtres : journalctl -u nginx -p err --since "2024-01-01" --until "2024-01-31" pour cibler précisément les erreurs d'un service sur une période donnée.
📖 Niveaux de run / targets
Les targets systemd remplacent les anciens runlevels de SysVinit :
| Runlevel (ancien) | Target systemd | Description |
|---|---|---|
| 0 | poweroff.target | Arrêt du système |
| 1 | rescue.target | Mode rescue (mono-utilisateur) |
| 3 | multi-user.target | Multi-utilisateur sans GUI |
| 5 | graphical.target | Multi-utilisateur avec GUI |
| 6 | reboot.target | Redémarrage |
| — | emergency.target | Shell d'urgence minimal |
# Voir la target par défaut
systemctl get-default
# Changer la target par défaut
sudo systemctl set-default multi-user.target
# Basculer immédiatement vers une target
sudo systemctl isolate rescue.target📖 Crontab vs systemd timers
Les timers systemd sont une alternative moderne à cron pour planifier des tâches :
| Critère | Crontab | systemd timer |
|---|---|---|
| Configuration | Fichier unique avec syntaxe spécifique | Deux fichiers : .timer + .service |
| Logs | Logs via mail ou redirection manuelle | Journalisation intégrée avec journalctl |
| Dépendances | Non | Oui (After, Requires) |
| Persistance | Non (tâche manquée = perdue) | Oui (Persistent=true) |
| Précision | À la minute | À la seconde ou au microseconde |
# Exemple de timer : backup quotidien
# /etc/systemd/system/backup.timer
[Unit]
Description=Backup quotidien à 2h du matin
[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
[Install]
WantedBy=timers.target
# Activer le timer
sudo systemctl enable --now backup.timer
# Lister les timers actifs
systemctl list-timers📖 Analyse du démarrage
L'outil systemd-analyze permet de diagnostiquer les performances de démarrage :
# Temps total de démarrage
systemd-analyze
# Détail par service (les plus lents en premier)
systemd-analyze blame
# Chaîne critique de démarrage
systemd-analyze critical-chain
# Générer un graphe SVG du démarrage
systemd-analyze plot > boot.svg📖 Dépendances et ordonnancement
systemd gère l'ordre de démarrage via des directives de dépendance :
| Directive | Description |
|---|---|
After= | Démarrer après l'unité spécifiée (ordonnancement uniquement) |
Before= | Démarrer avant l'unité spécifiée |
Requires= | Dépendance forte : si l'unité requise échoue, ce service échoue aussi |
Wants= | Dépendance faible : si l'unité souhaitée échoue, ce service démarre quand même |
BindsTo= | Lien fort : le service s'arrête si l'unité liée s'arrête |
After contrôle uniquement l'ordre de démarrage. Pour garantir qu'un service est bien démarré, combinez avec Requires ou Wants. Exemple : After=network.target + Requires=network.target.
📝 QCM — Testez vos connaissances
- Qu'est-ce que systemd ?
- Quelle commande démarre un service avec systemd ?
- Comment activer un service au démarrage ?
- Que contient un fichier .service de systemd ?
- Quelle commande affiche les logs d'un service ?
- Que remplace systemd par rapport aux anciens systèmes ?
📝 Afficher les corrections
- Le système d'initialisation et gestionnaire de services de Linux — systemd est le PID 1 sur la plupart des distributions modernes, il gère le démarrage et les services.
- systemctl start nom-du-service — systemctl start/stop/restart/status permettent de gérer les services.
- systemctl enable nom-du-service — enable crée un lien symbolique pour que le service démarre automatiquement au boot.
- La configuration du service (commande, dépendances, utilisateur) — Les fichiers .service dans /etc/systemd/system/ définissent ExecStart, After, User, Restart, etc.
- journalctl -u nom-du-service — journalctl interroge le journal systemd, -u filtre par unité (service), -f suit en temps réel.
- SysVinit et Upstart — systemd a remplacé SysVinit (scripts /etc/init.d/) et Upstart pour un démarrage parallèle plus rapide.
systemd est le gestionnaire central des services Linux modernes. Maîtrisez systemctl pour gérer les services, journalctl pour les logs, et sachez créer vos propres fichiers .service. Les timers systemd remplacent avantageusement cron pour les tâches planifiées.