SystemD, les développeurs aussi le maîtrise

Ce processus, le premier lancé, porte le PID 1, et a pour responsabilité principale l’initialisation du système et la gestion des processus. Historiquement, c’est un programme nommé systemV qui était en charge de cette gestion.

En 2010, Lennart Poettering, développeur chez Red Hat, considère que systemV n’est plus adapté aux systèmes modernes, dû à un démarrage séquentiel des services et une grande difficulté à définir des dépendances entre services. Il commence donc le développement d’un nouveau système d’initialisation nommé systemD, avec deux objectifs principaux :

• Accélérer le démarrage du système.
• Améliorer la supervision des services.

Comment accélérer le démarrage du système ?

Afin d’accélérer le processus de démarrage, Lennart Poettering part de deux observations simples :

• Il faut démarrer le moins de services possibles.
• Il faut démarrer le plus de services possibles en parallèle.

Par exemple, sur notre ordinateur, nous n’utilisons pas forcément le service d’impression (cups sur Linux). Pourtant, celui-ci est présent dès le démarrage du système. L’idéal serait que celui-ci se lance uniquement au moment où l’utilisateur souhaite imprimer.

Lancer les services en parallèle peut sembler à première vue une bonne idée, mais cela implique la résolution d’un arbre de dépendances avant même de lancer le premier service. Cette résolution peut, dans certains cas, être coûteuse en temps.

Sous Linux, la plupart des services communiquent entre eux via des sockets. Si on regarde simplement le problème de résolution de dépendances entre services, un service A qui dépend d’un service B, n’a pas vraiment besoin d’attendre que le service B soit complètement démarré avant de pouvoir lui-même démarrer ; Il a juste besoin que la socket du service B soit ouverte.

De même, si l’on reprend l’exemple de notre service d’impression, celui-ci n’a pas vraiment besoin d’être lancé dès le démarrage. Il suffit que la socket liée au service soit ouverte. Au moment où celle-ci recevra un fichier à imprimer, alors seulement il deviendra utile de démarrer un service d’impression. L’utilisateur final n’y voit pas de différence, mais notre système a pu se lancer plus rapidement.

On voit donc qu’en décorélant le lancement d’un service de celui de la socket qui lui est associée, on peut à la fois activer des services à la demande et résoudre le problème de la gestion des dépendances entre services. Ainsi, le système démarre uniquement les services indispensables, et peut également les démarrer en parallèle.

Comment mieux superviser les services lancés ?

La seconde problématique que tente de résoudre le systemD est la supervision des services qu’il lance. Arrêter un service signifie stopper l’ensemble des processus que celui-ci à lancer. Certains processus font ce que l’on appelle un « double fork » et ne sont donc plus rattachés à leur processus parent. Par conséquent, Ils ne se stoppent plus automatiquement lorsque leur processus parent s’arrête.

Il existe dans le noyau Linux une fonctionnalité appelée cgroups (controls groups), initialement conçu pour limiter les ressources (cpu, mémoire, etc.) allouées à un ensemble de processus. Les cgroups permettent aussi de regrouper des processus au sein d’un même groupe. SystemD utilise ce mécanisme afin d‘identifier les processus lancés par un service.

Grâce aux cgroups, SystemD peut superviser les services dont il a la charge, c’est-à-dire connaître leur statut (actif ou non), limiter les ressources qui leur sont attribuées, être capable de redémarrer automatiquement un service en cas de crash, etc. et connaître l’ensemble des processus que le service a lancés puis tous les arrêter.

SystemD est aujourd’hui adopté par la plupart des distributions majeures : Red Hat, Ubuntu, debian, centos, etc. Il offre enfin un cadre standard pour gérer les services sous Linux, là où auparavant chaque distribution apportait sa propre solution.