49

Pour aller plus loin sur ITPro.fr

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 paral-lè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 sys-tè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 à pre-mière vue une bonne idée, mais cela implique la résolu-tion 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 vrai-ment besoin d'attendre que le service B soit complète-ment 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 lan-cer plus rapidement.

On voit donc qu'en décorélant le lancement d'un ser-

Par Jean-Eudes Couignoux

Les déveLoppeurs aussi maîtrisent Le systemd

Infrastructure IT Expert

Sur un système Linux, le noyau lance ce que l'on appelle “process d'init”. 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.

Infrastructure IT Expert

TechDays 2014 – « Le développeur doit participer aux décisions au plus haut niveau » bit.ly/développeur-participer-décisions

Bientôt un visa pour les développeurs étrangers ? bit.ly/visa-developpeurs-etrangers

50 N° 146 | Juin 2015 | IT Pro Magazine

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 ser-vices dont il a la charge, c'est-à-dire connaître leur sta-tut (actif ou non), limiter les ressources qui leur sont attribuées, être capable de redémarrer automatique-ment un service en cas de crash, etc. et connaître l’en-semble des processus que le service a lancés puis tous les arrêter.

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

Jean-Eudes CouignouxConsultant chez Xebia

vice 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 ser-vices. Ainsi, le système démarre uniquement les ser-vices 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 pro-cessus 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 pro-cessus parent s’arrête.

Il existe dans le noyau Linux une fonctionnalité appe-lée cgroups (controls groups), initialement conçu pour limiter les ressources (cpu, mémoire, etc.) allouées à

Retrouvez plus de 4 200 dossiers dédiésaux professionnels de l'informatique d'entreprise sur :

C o n s e i l e t E x p e r t i s e I T

Votre mensuel informatique pour vous accompagner dans le choix, la gestion

et l'optimisation de vos environnements informatiques professionnels

iTPro.fr