Introduction

Le système d'initialisation, ou système d’init, est une composante essentielle du noyau

Linux, responsable de la gestion des processus dès le démarrage de l’ordinateur. Au fil des
décennies, plusieurs systèmes d’init ont été utilisés sous Linux, chacun ayant ses propres
avantages et limitations. L’introduction de Systemd marque une étape importante dans
l’évolution des systèmes Linux.

1.1 Historique des systèmes d'init sous Linux

1.1.1 SysVinit
SysVinit est l'un des premiers systèmes d'initialisation utilisés sous Linux, basé sur le
concept d’un système d'init System V Unix.
Fonctionnement :
SysVinit suit un processus séquentiel où les scripts d'init (localisés dans /etc/init.d/) sont
exécutés dans un ordre prédéfini pour démarrer les services. Chaque niveau d'exécution
(runlevel) correspond à un état spécifique du système (par exemple, multi-utilisateurs, mode
graphique, etc.).
Limites :
● Démarrage séquentiel, entraînant un ralentissement.
● Gestion limitée des dépendances entre services.
● Difficulté à redémarrer ou gérer des services individuellement.

1.1.2 Upstart
Upstart a été introduit comme une alternative à SysVinit, développée par Canonical pour
Ubuntu.
Fonctionnement :
Upstart utilise un système d'événements pour gérer les services, ce qui signifie que les
tâches peuvent être déclenchées en fonction d'événements spécifiques (par exemple,
l’apparition d’un périphérique ou le montage d’un système de fichiers).
Avantages :
● Exécution parallèle de certains services.
● Réactivité aux événements du système.
Limites :
● Complexité accrue dans la gestion des scripts.
● Manque de compatibilité avec les scripts SysVinit existants.

1.1.3 Systemd
Systemd, introduit en 2010 par Lennart Poettering et Kay Sievers, est devenu le système
d’init par défaut de nombreuses distributions Linux modernes.
Fonctionnement :
Systemd introduit le concept d'unités (units) pour une gestion centralisée des services,
processus, et dépendances. Il utilise également les groupes de contrôle (cgroups) pour une
gestion fine des ressources.
Avantages :

● Gestion parallèle des services pour accélérer le démarrage.

● Prise en charge native des dépendances entre unités.
● Journalisation centralisée et gestion dynamique des services.
1.2 Objectif principal de Systemd
L'objectif principal de Systemd est de répondre aux limitations des systèmes d'init
précédents tout en introduisant des fonctionnalités modernes. Voici quelques objectifs clés :
Standardisation : Offrir une interface uniforme pour la gestion des services sur toutes les
distributions Linux.
Performance : Réduire le temps de démarrage grâce à une exécution parallèle et une
gestion optimisée des dépendances.
Flexibilité : Introduire un système modulaire basé sur des unités qui permettent une
personnalisation fine des services et des processus.
Centralisation : Regrouper des fonctionnalités auparavant dispersées (journalisation, gestion
des ressources, etc.) sous une seule entité.

1.3 Présentation générale des fonctionnalités de Systemd

Systemd se distingue par plusieurs fonctionnalités qui le rendent indispensable pour les
systèmes Linux modernes :
Gestion des unités : Chaque service, tâche ou cible est défini comme une unité
(fichiers .service, .target, .timer, etc.), facilitant leur configuration et gestion.
Démarrage parallèle : Systemd optimise le temps de démarrage en exécutant les services
simultanément, en fonction des dépendances définies.
Activation à la demande : Certains services peuvent être démarrés automatiquement
lorsqu’ils sont sollicités, grâce à l’utilisation de sockets.
Journalisation centralisée : Avec journald, tous les événements du système sont enregistrés
de manière centralisée et accessible via la commande journalctl.
Gestion des ressources avec cgroups : Systemd utilise les groupes de contrôle pour allouer
et surveiller les ressources consommées par les services et processus.
Compatibilité ascendante : Systemd peut gérer des scripts d'init SysVinit existants pour
faciliter la transition.

Ces fonctionnalités font de Systemd une solution puissante, intégrée et adaptée aux besoins
des systèmes modernes.

2. Les bases de Systemd

Systemd constitue une révolution dans la manière dont les services et les processus sont
gérés dans les systèmes Linux modernes. Comprendre ses bases est essentiel pour utiliser
pleinement ses fonctionnalités.
2.1 Définition et concept des unités
Systemd repose sur le concept d’unités , qui représentent des ressources ou des services
gérés par le système d’exploitation.
Définition :
Une unité est un fichier de configuration décrivant un élément à gérer, comme un service, un
point de montage, un socket, ou encore une tâche planifiée.
Caractéristiques des unités :
Modularité : Chaque unité est indépendante et peut être configurée séparément.
Flexibilité : Les unités peuvent être combinées ou activées en fonction des besoins.

Types variés : Services, temporisateurs, points de montage, etc.

Chaque unité est identifiée par un nom unique, généralement accompagné d’une extension
définissant son type (par exemple, [Link] pour un service).

2.2 Architecture et localisation des fichiers

Systemd suit une architecture hiérarchique qui facilite la gestion et la personnalisation des
fichiers de configuration.
Localisation des fichiers d’unités :
1. Répertoires principaux :
/usr/lib/systemd/system/ : Contient les fichiers d’unité installés par les paquets logiciels.
/etc/systemd/system/ : Contient les fichiers d’unité personnalisés ou spécifiques à
l’administrateur.
/run/systemd/system/ : Répertoire temporaire pour les unités générées dynamiquement.
2. Priorité de lecture :
Lors du démarrage, Systemd lit les unités dans cet ordre :
/etc/systemd/system/
/run/systemd/system/
/usr/lib/systemd/system/
Les fichiers d’unité dans /etc/systemd/system/ ont la priorité et peuvent remplacer ceux des
autres répertoires.
Organisation interne :
Les fichiers d’unité sont structurés en sections, chacune décrivant un aspect spécifique :
[Unit] : Dépendances, description.
[Service] : Configuration des processus pour les services.
[Install] : Instructions pour l’activation/désactivation au démarrage.

2.3 Pourquoi Systemd est devenu le standard

Systemd a surmonté les limitations des systèmes d’init précédents comme SysVinit et
Upstart en introduisant des fonctionnalités innovantes :
Performance : Démarrage plus rapide grâce à l’exécution parallèle des services.
Gestion avancée des dépendances : Les unités peuvent déclarer des dépendances
explicites, ce qui garantit un ordre d’exécution optimal.
Centralisation : Systemd intègre des fonctionnalités comme la journalisation (journald) et la
gestion des ressources (cgroups) dans une seule suite.
Interopérabilité : Prise en charge des scripts SysVinit existants pour faciliter la transition.
Ces caractéristiques ont conduit la majorité des distributions Linux à adopter Systemd
comme système d’init par défaut.
3. Les unités Systemd
Les unités constituent la base de l’architecture de Systemd. Comprendre leurs types, leur
structure, et comment les personnaliser est crucial pour tirer parti de Systemd.

3.1 Types d'unités

Systemd prend en charge plusieurs types d’unités, chacun répondant à un besoin spécifique
:
Service units (.service) : Gestion des services de démarrage et d’arrêt (par exemple,
[Link]).
Target units (.target) : Groupement logique d’autres unités (par exemple, [Link]).
Socket units (.socket) : Activation à la demande de services basés sur des sockets (par
exemple, [Link]).
Timer units (.timer) : Remplacement moderne des tâches cron pour la planification.
Mount units (.mount) : Gestion des points de montage de systèmes de fichiers.
Device units (.device) : Gestion des périphériques détectés par udev.
Path units (.path) : Surveillance de chemins spécifiques dans le système de fichiers.
Chaque type d’unité a des options spécifiques pour répondre à son rôle.
3.2 Structure et syntaxe d’un fichier d’unité
Les fichiers d’unité suivent une structure standardisée en trois sections principales :
1. Section [Unit] :
Décrit les métadonnées et dépendances de l’unité.
Exemples :
Description=Mon service personnalisé
After=[Link]
Requires=[Link]
2. Section [Service] (pour les services) :
Contient les commandes de démarrage, d’arrêt et de redémarrage.
Exemples :
ExecStart=/usr/bin/my-service
ExecStop=/usr/bin/stop-my-service
Restart=always
3. Section [Install] :
Définit le comportement d’activation au démarrage.
Exemple :
WantedBy=[Link]

3.3 Création et modification d'unités personnalisées

Créer une unité personnalisée permet d’ajouter des services ou des tâches spécifiques :
Étapes pour créer une unité :
1. Créer un fichier d’unité :
Exemple : /etc/systemd/system/[Link].
2. Rédiger la configuration :
[Unit]
Description=Service personnalisé
After=[Link]

[Service]
ExecStart=/usr/local/bin/[Link]
Restart=on-failure

[Install]
WantedBy=[Link]
3. Activer et démarrer l’unité :
Charger la nouvelle configuration :
systemctl daemon-reload
Activer le service au démarrage :
systemctl enable [Link]
Démarrer le service :
systemctl start [Link]
Modification et débogage :
Pour modifier une unité, éditez son fichier dans /etc/systemd/system/, puis rechargez les
configurations avec systemctl daemon-reload.
Utilisez systemctl status [Link] pour diagnostiquer les problèmes.

4. Commandes essentielles de Systemd

Systemd est principalement contrôlé à l'aide de la commande systemctl, un outil puissant
pour la gestion des services, des unités et de l'état du système.

4.1 Gestion des services avec systemctl

systemctl est utilisé pour gérer les services dans Systemd. Voici les commandes
essentielles :
Démarrer un service :
systemctl start nom_du_service.service
Arrêter un service :
systemctl stop nom_du_service.service
Redémarrer un service :
systemctl restart nom_du_service.service
Recharger la configuration d’un service sans l’arrêter :
systemctl reload nom_du_service.servicye
Combinaison de rechargement et redémarrage si nécessaire :
systemctl reload-or-restart nom_du_service.service.

4.2 Activation et désactivation des services

L’activation d’un service garantit qu’il démarre automatiquement au prochain redémarrage.
Activer un service au démarrage :
systemctl enable nom_du_service.service
Désactiver un service au démarrage :
systemctl disable nom_du_service.service
Vérifier si un service est activé :
systemctl is-enabled nom_du_service.service
Masquer un service pour empêcher son démarrage manuel ou automatique :
systemctl mask nom_du_service.service
Démasquer un service :
systemctl unmask nom_du_service.service

4.3 Vérification des statuts des services et du système

Vérifier le statut d’un service :
systemctl status nom_du_service.service
Cela affiche des informations sur l’état du service, son PID, ses journaux récents, et plus
encore.
Lister tous les services actifs :
systemctl list-units --type=service
Vérifier l’état global du système :
systemctl is-system-running
Possible réponses : running, degraded, maintenance, etc.
5. Journalisation et diagnostic avec Systemd
Systemd intègre une journalisation centralisée avec journald, qui enregistre les événements
système et les messages des services.

5.1 Rôle et configuration de journald

journald est conçu pour collecter et stocker les journaux du système :
Par défaut, les journaux sont conservés en mémoire ou sur disque (selon la configuration).
Fichier de configuration principal : /etc/systemd/[Link].
Paramètres principaux :
Storage= : Définit où les journaux sont stockés (volatile, persistent, etc.).
MaxRetentionSec= : Définit la durée maximale de conservation des journaux.

5.2 Utilisation de journalctl pour analyser les logs

journalctl est l’outil principal pour interagir avec les journaux.
Afficher tous les journaux :
journalctl
Filtrer les journaux par service :
journalctl -u nom_du_service.service
Afficher les journaux récents :
journalctl -e
Surveiller les journaux en temps réel :
journalctl -f

5.3 Dépannage des services défaillants

Pour diagnostiquer un problème, combinez les outils suivants :
1. Vérifiez le statut du service :
systemctl status nom_du_service.service
2. Consultez les journaux associés :
journalctl -u nom_du_service.service
3. Identifiez les erreurs système :
journalctl -p err

6. Sécurité et isolation
Systemd intègre plusieurs mécanismes puissants pour renforcer la sécurité et isoler les
services, garantissant un fonctionnement sécurisé et stable des systèmes Linux.

6.1 Gestion des permissions des unités

Chaque unité Systemd peut être configurée pour fonctionner avec des permissions
spécifiques, réduisant ainsi les risques de sécurité liés aux accès non autorisés.

1. Exécution en tant qu’utilisateur spécifique :

Dans le fichier d’unité, utilisez la directive User= pour spécifier l’utilisateur sous lequel le
service doit fonctionner.
Exemple :
[Service]
User=backup
ExecStart=/usr/local/bin/[Link]
Cela garantit que le service n’aura pas les privilèges de l’administrateur système (root),
limitant son impact en cas de compromission.

2. Groupes restreints :
Utilisez Group= pour limiter le groupe auquel appartient le service.
Exemple :
Group=backup

3. Réduction des privilèges :

Avec CapabilityBoundingSet=, vous pouvez spécifier les capacités Linux nécessaires à
l’unité, empêchant l’accès aux autres.
Exemple :
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_CHOWN
Cela limite le service à la liaison sur un port réseau et à la modification de la propriété des
fichiers.
4. Protection des fichiers système :
Empêchez le service d’accéder aux fichiers système critiques en activant des options
comme :
ProtectSystem=full : Rend /usr et /boot accessibles en lecture seule.
ProtectHome=yes : Empêche l’accès aux répertoires utilisateur (/home).

6.2 Utilisation des cgroups pour limiter les ressources

Systemd repose sur les cgroups (control groups) du noyau Linux pour limiter et isoler les
ressources utilisées par les services.
1. Limitation des ressources CPU :
Utilisez CPUQuota= pour définir un pourcentage maximum de CPU que le service peut
utiliser.
Exemple :
[Service]
CPUQuota=50%
Cela limite le service à 50 % de la capacité totale du CPU.
2. Limitation de la mémoire :
Configurez MemoryMax= pour définir une limite stricte sur l’utilisation de la mémoire.
Exemple :
MemoryMax=500M
Cela limite l’utilisation à 500 Mo.
3. Isolation d’E/S :
Avec IOWeight=, vous pouvez prioriser les E/S du service par rapport aux autres.
Exemple :
IOWeight=500
4. Ressources spécifiques :
Utilisez des directives telles que :
TasksMax= : Limite le nombre de processus/fils pouvant être créés.
DeviceAllow= : Contrôle l’accès à des périphériques spécifiques.
Exemple :
DeviceAllow=/dev/null rw
6.3 Sandboxing des services pour améliorer la sécurité
Systemd permet de sandboxer les services pour les isoler complètement du reste du
système. Voici les principales options de sandboxing :
1. Restriction des accès réseau :
PrivateNetwork=yes : Crée une pile réseau privée pour le service, empêchant tout accès
direct au réseau principal.
2. Répertoires privés :
ProtectSystem=full : Rend les répertoires système en lecture seule.
PrivateTmp=yes : Crée un répertoire /tmp spécifique au service.
3. Verrouillage des fichiers système :
ProtectKernelModules=yes : Empêche le service de charger ou décharger des modules du
noyau.
ProtectKernelTunables=yes : Bloque l’accès aux paramètres du noyau via /proc ou /sys.
4. Isolation des répertoires :
ReadOnlyPaths= : Définit des répertoires accessibles uniquement en lecture.
InaccessiblePaths= : Rends certains chemins inaccessibles pour le service.
Exemple :
ReadOnlyPaths=/etc
InaccessiblePaths=/boot
5. Droits restreints :
NoNewPrivileges=yes : Empêche l'élévation de privilèges pour le processus ou ses sous-
processus.
6. Environnement minimal :
ProtectClock=yes : Empêche la modification des paramètres d’horloge du système.
ProtectHostname=yes : Empêche le service de modifier le nom d’hôte.
7. Exemple complet de fichier d’unité sandboxé :
Unit]
Description=Service isolé

[Service]
ExecStart=/usr/local/bin/[Link]
User=secure_user
PrivateTmp=yes
ProtectSystem=full
ProtectKernelModules=yes
NoNewPrivileges=yes
MemoryMax=100M
CPUQuota=30%

[Install]
WantedBy=[Link]

Ces techniques de sécurité et d’isolation font de Systemd un outil fiable pour protéger les
services critiques et minimiser les risques associés aux processus non sécurisés. En
combinant la gestion fine des permissions, les cgroups et les options de sandboxing, vous
pouvez garantir un environnement stable et sécurisé
7. Avantages et critiques de Systemd.

7.1 Points forts

Systemd s'est imposé comme le système d'init par défaut dans de nombreuses distributions
Linux grâce à ses nombreux avantages :
1. Performance accrue :
Démarrage parallèle des services, réduisant le temps de boot.
Gestion des dépendances intelligente, exécutant uniquement les services nécessaires.
2. Modularité :
Chaque composant de Systemd est autonome mais interconnecté, permettant une flexibilité
dans l’utilisation.
Possibilité de configurer et d’utiliser des services spécifiques à l’environnement ou à
l’utilisateur.
3. Journalisation centralisée avec journald :
Un point central pour collecter et analyser les journaux des services et du système.
Permet un diagnostic précis grâce à la corrélation des événements.
4. Intégration des cgroups :
Offre un contrôle précis sur les ressources consommées par les services.
Améliore la gestion de la sécurité et de l’isolation des processus.
5. Interopérabilité :
Compatibilité avec les scripts d’init traditionnels (SysV et LSB).
Intégration avec des outils modernes comme Docker et Kubernetes.

7.2 Limites et controverses autour de Systemd

Bien que puissant, Systemd n’est pas exempt de critiques :
1. Complexité accrue :
La centralisation de nombreuses fonctionnalités dans un seul système peut le rendre difficile
à comprendre et à gérer pour les nouveaux utilisateurs.
Les erreurs dans Systemd peuvent affecter de nombreux aspects du système.
2. Critique de la philosophie UNIX :
Certains puristes estiment que Systemd viole le principe « Do one thing and do it well » en
intégrant de multiples fonctionnalités (init, journalisation, cgroups, etc.) dans un seul outil.
3. Taille et monopole :
Systemd est jugé trop volumineux par rapport à ses prédécesseurs, ce qui augmente la
surface d’attaque potentielle pour des failles de sécurité.
Sa popularité a conduit à une dépendance de nombreuses distributions, rendant difficile
l’adoption d’alternatives.
4. Critiques sur le design :
Certains développeurs estiment que la conception de Systemd manque de transparence et
de clarté.
8. Études de cas pratiques

8.1 Création d’un service personnalisé

Objectif :
Créer un service pour exécuter un script de sauvegarde automatisée.

1. Créer le script (/usr/local/bin/[Link]) :

#!/bin/bash
tar -czf /backup/data-$(date +%F).[Link] /data
Rendez le script exécutable :
chmod +x /usr/local/bin/[Link]
2. Créer le fichier d’unité (/etc/systemd/system/[Link]) :

[Unit]
Description=Service de sauvegarde
After=[Link]

[Service]
ExecStart=/usr/local/bin/[Link]
Restart=on-failure

[Install]
WantedBy=[Link]
3. Activer et démarrer le service :
systemctl daemon-reload
systemctl enable [Link]
systemctl start [Link]

8.2 Configuration d’un timer pour automatiser des tâches

Objectif :
Exécuter le script de sauvegarde quotidiennement à 2 heures du matin.
1. Créer le fichier timer (/etc/systemd/system/[Link]) :
[Unit]
Description=Planificateur de sauvegarde

[Timer]
OnCalendar=*-*-* [Link]
Persistent=true

[Install]
WantedBy=[Link]
2. Activer le timer :
systemctl enable [Link]
systemctl start [Link]
3. Vérifier le statut du timer :
systemctl list-timers
8.3 Analyse des logs et dépannage d’un service
1. Vérifier le statut d’un service :
systemctl status [Link]
Cela fournit des informations sur l’état actuel du service.
2. Analyser les journaux du service :
journalctl -u [Link]
Cette commande permet d’identifier les éventuelles erreurs.
3. Corriger les erreurs détectées :
Après avoir corrigé les problèmes, redémarrez le service :
systemctl restart [Link]

9. Conclusion
Systemd a transformé la gestion des systèmes Linux modernes grâce à :
Un démarrage rapide et optimisé par l’exécution parallèle des [Link] gestion
centralisée des dépendances et des [Link] flexibilité accrue grâce à la modularité
et aux unités [Link] outils intégrés comme journald pour une journalisation
[Link] que critiqué pour sa complexité et son éloignement des principes UNIX
traditionnels, Systemd a su s’imposer comme une solution robuste et polyvalente.
9.1 Impact de Systemd sur l’écosystème Linux
Systemd a modifié profondément l’écosystème Linux :
1. Adoption généralisée : La plupart des grandes distributions Linux (Ubuntu, Fedora,
Debian, etc.) l’ont intégré, uniformisant les pratiques de gestion des systèmes.
2. Accélération des innovations : Systemd a ouvert la voie à de nouvelles approches dans la
gestion des services et des ressources.
3. Controverses constructives : Les critiques ont conduit à l’amélioration continue de
Systemd, tout en stimulant le développement d’alternatives (comme OpenRC et Runit).

En conclusion, Systemd est aujourd’hui un outil incontournable pour tout administrateur ou

utilisateur souhaitant maîtriser pleinement son système Linux.