Après un débat passionné, la décision a finalement été prise : la prochaine version GNU/Linux de Debian utilisera par défaut systemd en guise de successeur à SysVinit. Le débat avait convergé vers une dichotomie avec les partisans de systemd d'un côté, et ceux d'upstart de l'autre. D'autres successeurs ont été proposés, voire même l'absence de successeur et un maintien de SysVinit.
SysVinit se compose d'un ensemble de programmes qui contrôlent les fonctions basiques du système. Parmi ces programmes, on trouve init, qui est le premier programme exécuté par le noyau au démarrage du système. Le programme init est responsable du lancement et de l'arrêt de tous les autres programmes, configurés en tant que services.
C'est donc d'une brique des plus critiques du système qu'il a été question, ce qui explique en partie l'intensité des débats.
Exemple de service SysVinit
Un service SysVinit se présente généralement sous la forme d'un script shell dont le premier argument indique la commande à effectuer. SysVinit se repose sur un ensemble de commandes standards comme start, stop, restart et status par exemple.
L'écriture du script est assez répétitive, on le structure généralement de la manière suivante :
#!/bin/sh
# fonctions utilitaires et configuration
. /etc/init.d/functions
. /etc/mon_service/ma_conf
start() {
# commandes pour démarrer le service
/usr/sbin/mon_daemon $MES_OPTIONS
}
stop() {
# commandes pour arrêter le service
...
}
status() {
# commandes pour connaître l'état du service
...
}
case "$1" in
start|stop|status)
$1
;;
restart|reload)
stop
start
;;
esac
Les services enregistrés auprès de SysVinit seront donc démarrés ou arrêtés en faisant appel à ce type de script.
Exemple de service systemd
L'approche de systemd est radicalement opposée à celle de SysVinit. Systemd se configure de manière purement déclarative. Là où SysVinit suppose de mettre en oeuvre soi-même l'arrêt d'un service et donc des processus associés, systemd prendra connaissance de tous les processus démarrés par un service et sera par défaut capable de les arrêter de lui-même.
La déclaration d'un service se concentre généralement sur l'essentiel :
[Unit] Description=Mon service Documentation=man:mon_service(8) [Service] EnvironmentFile=/etc/mon_service/ma_conf PIDFile=/var/run/mon_service.pid ExecStart=/usr/sbin/mon_daemon $MES_OPTIONS
Systemd utilise un format de fichier proche des fichiers INI sous Windows.
Exemple de service upstart
Upstart quant à lui se situe à mi-chemin entre les deux avec une part de déclaratif et une part de programmatique. Le système repose sur la notion d'évènements, il est donc possible d'émettre ou de réagir à des événements.
# exemple d'action liée à un évènement
start on starting mon_autre_service
script
. /etc/mon_service/ma_conf
exec /usr/sbin/mon_daemon $MES_OPTIONS
emit mon_evenement
end script
SysVinit, systemd et upstart sont bien entendu capables de faire beaucoup plus. Un des reproches faits à systemd est justement d'en faire trop et de prendre bien plus de responsabilités qu'un système d'initialisation ne le devrait.
Pour en savoir plus sur la teneur des débats, InfoQ a rencontré Stephen Kitt.
InfoQ FR : Bonjour Stephen, et merci de répondre à nos questions, peux-tu te présenter ?
Stephen : Bonjour Dridi, c'est un plaisir. Je suis un féru d'informatique, Architecte chez ERDF le jour, et Développeur Debian le reste du temps !
InfoQ FR : Il y a quelques temps, systemd a été choisi comme système d'initialisation par défaut pour Debian. Le débat a déchaîné les passions, peux-tu nous en dire plus ?
Stephen : En effet, on peut parler de déchaînement de passions, même si finalement le nombre de Développeurs impliqués dans les débats est faible par rapport au nombre total de Développeurs dans le projet. La place de systemd dans le projet est un sujet qui couvait depuis longtemps. Le paquet systemd est dans Debian depuis 2010 et provoque des débats animés depuis juillet 2011. Upstart provoquait aussi de longues discussions ; par exemple celle-ci et la suite.
Le débat qui a connu sa conclusion en début d'année avait repris juste avant l'été 2013 et a alimenté pas mal de discussions à la conférence annuelle Debian, DebConf13. Les organisateurs avaient invité Lennart Poettering, qui a présenté le côté systemd des choses avec l'aide des Développeurs Debian en charge de l'écosystème systemd, et côté Upstart certains développeurs Ubuntu, qui sont aussi dans Debian depuis fort longtemps (avant Ubuntu), ont porté haut leurs couleurs. Lors de la conférence, le consensus était que le choix d'un système d'initialisation par défaut ne se règlerait pas "comme ça", et qu'il faudrait soit une résolution générale du projet, soit une décision du comité technique. C'est cette dernière option qui a été de facto retenue puisque le comité technique (TC) a été saisi de la question.
InfoQ FR : Quel est le rôle du comité technique au sein du projet Debian ?
Stephen : La constitution Debian prévoit un certain nombre d'instances de décision dans le projet : d'abord les membres du projet, en autonomie ou via les résolutions générales votées par tous les membres ; ensuite le "Project Leader", élu tous les ans ; ensuite le "Technical Committee" (TC). Les membres du TC sont des Développeurs Debian (membres du projet), nommés par le Project Leader généralement sur recommandation des autres membres du TC. Le rôle du TC est de donner des avis sur des questions techniques, notamment lorsque plusieurs Développeurs n'arrivent pas à se mettre d'accord.
En règle générale, Debian fonctionne comme une "do-ocracy", c'est-à-dire que celui qui fait a raison, jusqu'à ce que quelqu'un d'autre fasse mieux. Dans le cas qui nous intéresse, les différentes options étaient capables de faire, mais faire d'un système d'initialisation le système par défaut implique l'adhésion de tous les responsables de paquets affectés (tous les daemons par exemple). Avec l'intégration de plus en plus poussée, d'autres parties ont un avis intéressé, par exemple les responsables de Gnome qui dépend de plus en plus de systemd. Du coup, il fallait un avis tranché ; et pour aboutir à un avis définitif, il était sans doute plus simple de demander un vote du TC qu'un vote sur une résolution générale.
InfoQ FR : Ce qui ressortait des débats était la décision qui s'orientait vers le statu quo, systemd ou upstart. Peux-tu nous présenter rapidement ces trois systèmes ?
Stephen : Le statu quo, c'est System V init : des scripts dans /etc/init.d, un runlevel qui détermine ce qui s'exécute, et globalement un système plutôt statique qui ne réagit pas après le démarrage du système.
Upstart est le gestionnaire d'événements déployé dans Ubuntu jusqu'à maintenant : il s'occupe du démarrage, mais aussi des changements après le démarrage (branchement de périphériques, changement de réseau...).
systemd est issu indirectement d'Upstart, et suit les mêmes grands principes avec une volonté d'intégration plus poussée. Il s'occupe du démarrage et des événements grosso-modo comme Upstart, mais intègre maintenant aussi la gestion des logins, la vie des démons après leur lancement, les logs...
Thomas Goirand a vaillamment défendu une quatrième option, OpenRC, qui est le gestionnaire de démarrage utilisé sur Gentoo. Je n'en sais malheureusement pas plus !
L'idée principale est qu'on a maintenant des systèmes dynamiques, qui ne gardent pas la même configuration pendant leur exécution. On rajoute des disques, on en enlève, on utilise son portable différemment au bureau et en déplacement... System V Init n'est pas capable de bien gérer ça, les autres systèmes d'init tentent de mieux intégrer toutes les problématiques résultantes, avec des approches différentes.
InfoQ FR : Un des arguments à l'encontre de systemd était celui de la portabilité. Pourtant systemd est utilisé par plusieurs distributions Linux comme Arch et Fedora.
Stephen : Un des grands principes de systemd est d'utiliser à fond toutes les possibilités offertes par le noyau Linux. Une des premières a été les cgroups, qui permettent d'identifier des groupes de processus apparentés et de les gérer de façon ensembliste ; c'est idéal pour suivre un démon et tous les processus qu'il peut démarrer, par exemple un serveur Apache httpd avec des processus CGI ou FastCGI derrière.
Ce principe pose problème dans Debian, puisque Debian, c'est Debian GNU/Linux, mais aussi GNU/kFreeBSD et GNU/Hurd : nos utilisateurs n'utilisent pas systématiquement un noyau Linux.
Nos développeurs ont l'habitude de gérer ça, et sont tout à fait à même de patcher la plupart des logiciels dont ils s'occupent dans Debian pour qu'ils fonctionnent sur kFreeBSD ou Hurd ; mais nous préférons pouvoir "upstreamer" (ndt faire remonter les correctifs au projet en amont) ce genre de patch, pour éviter de devoir refaire le travail à chaque nouvelle version, et les développeurs systemd ne sont pas du tout intéressés. Donc, non seulement il serait très difficile d'adapter certaines des fonctionnalités de systemd sur kFreeBSD ou Hurd, mais en plus ce travail resterait cantonné à Debian ou à un éventuel fork de systemd...
InfoQ FR : Les développeurs de systemd n'acceptent pas les contributions de Debian, mais Upstart pose également un problème à ce niveau-là.
Stephen: Je vais modérer le propos : j'imagine que les développeurs systemd accepteront volontiers les contributions de Debian qui correspondent à leur vision de leur projet, comme tout responsable de projet qui intègre des modifications venues d'ailleurs !
Pour en venir à Upstart, en effet, les contributions Debian pouvaient poser problème. Pas d'un point de vue technique cette fois, mais d'un point de vue licence : comme la plupart des projets Canonical, pour envoyer une modification à Upstart, il faut signer un "Contributor's License Agreement". La première version du CLA Canonical prévoyait que la propriété du code contribué devait revenir à Canonical, et beaucoup se sont arrêtés à cette version ; elle a cependant été revue depuis pour n'exiger maintenant qu'une licence, c'est-à-dire que Canonical a le droit de réutiliser le code contribué comme il le souhaite. Ceci pose problème pour beaucoup puisque rien n'interdit à Canonical d'exploiter du code contribué, mais avec une licence propriétaire... Et nombreux sont ceux qui se méfient des motivations de Canonical !
Du coup les deux options intéressantes en présence (désolé Thomas !) étaient irrecevables pour certaines parties de la population Debian, pour des raisons différentes, ce qui compliquait le débat.
InfoQ FR : Au final, systemd a été choisi à une voix près, et Mark Shuttleworth a créé la surprise en annonçant qu'Ubuntu suivrait Debian dans son choix de systemd.
Stephen : En effet. Le TC était divisé entre Upstart et systemd, et il a fallu le vote décisif du président du TC, Bdale Garbee, pour départager. Ce n'était jamais arrivé auparavant : d'habitude les décisions du TC sont consensuelles au sein du TC. Ceci explique en partie certaines réactions dans le TC à l'issue du vote...
La décision de Mark Shuttleworth a été de mon point de vue salvatrice. Après le vote, il y a eu quelques soubresauts des partisans du statu quo, mais à ce stade tout le monde en avait assez et voulait juste passer à la suite. Le fait qu'Ubuntu suive la décision de Debian a achevé de légitimer le résultat du vote : l'"opposant" principal, Upstart, déposait de fait les armes...
InfoQ FR : Merci Stephen, et à bientôt sur InfoQ !
Stephen : Merci à toi, ce fut un plaisir !