est-ce que vous pourriez m'expliquer pourquoi systemd est-il si critiqué ?
De nombreuses raisons, mais voici les principales :
sytemd ne dialogue vraiment qu'avec dbus, si dbus ne se lance pas la machine n'a plus d'init, ou tout du moins plus un init normal, ce qui implique de faire des tests doublé pour la cohérence d'état des machines, un ou dbus démarre, un ou dbus ne démarre pas (ou pas au moment attendu). En plus le coté dialogue exclusif avec dbus nécessite l'utilisation d'un client dbus avec de gros droits si on veut pouvoir traquer un bug qui se déclare à l'init. Cette outil devra être exempt des sécurités cgroups et devra pouvoir accéder à tous les services. Ca fait une faille potentielle de plus.
systemd n'est pas compatible avec autre chose que Linux, et même pas avec autre chose que GNU/Linux à la sauce Red Hat. Bon nombre de configuration de type disques chiffrés/partition délocalisées/configuration dynamique ne sont tout simplement plus possible avec systemd qui s'attend à ce que certains éléments soient à une place bien précise avec des droits bien précis et un ordre de démarrage fixe. Notament au niveau du réseau on retrouve des défauts qui apparaissaient déjà sur networkmanager, par exemple quand il faut d'abord créer un lien VPN (PPTP, GRE ou autre) AVANT de créer une carte réseau et de lancer la couche TCP/IP. De la même façon tous les points de montage locaux sont systématiquement montés avant de lancer le moindre démon. C'est con pour Oracle par exempel qui a besoin de prendre le controle de certains points de montage en RAW et dont le montage normal ne sert qu'au debug et au cold backup. A partir de là systemd prive linux de choses importantes qu'il sait faire (et même bien faire) aujorud'hui - et il oblige en plus les devs à créer plusiseurs version de leur script d'init en fonction de la machine sur laquelle ils sont supposés s'éxecuter.
systemd pose un problème aux outils de contrôle : un truc aussi bête que apachectl devient un casse tête avec systemd, plusieurs utilisateurs peuvent controller le logiciel apache avec cet outil. Mais alors quid de systemd ? Est-ce qu'on ajoute des fonctionnalité DBus à l'outil pour lui permettre de dialoguer avec systemd pour lui dire "au fait le recharge la config" ou est-ce que l'on fait ça dans son dos en esperant qu'ils ne panique pas en voyant les processus apaches se fermer et s'ouvrir du fait d'appels à un outils qui n'est pas dans le même cgroup ? Ou alors est-ce que l'on met tout le monde dans le même cgroup, auquel cas quand on essaye de tuer un apache planté on commence par tuer l'outil qui permet d'interragir avec apache ?
(Bon pour apache les soucis sont résolus rapidement, mais pour tomcat déjà ca se complique et je ne parle pas d'Erlang ou d'autres applis distribuées)
chat échaudé craint l'eau froide : C'est pas comme si les "nouvelles API qui tuent tout" avaient une espérance de vie limité sous Linux, mais ca fait quand même 5 fois en 10 ans que l'on change complètement le paradigme d'acès au périphériques. Linux n'a pas une super réputation sur la pérénité de ses api, et pas mal de mainteneurs commencent sérieusement à en avoir marre de réinventer la roue. Devoir refaire toute la config à cause de polkit/consolekit/udev/hal qui s'enva/dbus/systemd ca amuse 5 minutes, mais là ca fait 3 ans.
Pour l'instant à moins d'une évolution très très léchée du produit par RH on est toujours obligé de gruiker les scripts pour que systemd fasse ce dont tu as besoin et pas ce qu'il veut, notamment pour les processus qui forkent dans tous les sens et qui n'ont pas de support natif de DBus. Et comme DNS, Apache et Postfix ne sont pas supposé en avoir quoi que ce soit à faire de systemd (et qu'en plus les dialogues avec systemd ne peuvent qu'avoir un impact négatif sur les perfs) ils n'auront probablement jamais de support DBus.
En fait une application unique ne peut pas faire la surveillance/le controle/le restart etc. de toutes les applis possibles et imaginables dans toutes les config possibles et imaginables - ca parait évident dit comme ça mais c'est pourtant ce qu'il essaye de faire. Donc systemd échouera, ou se pervertira jusqu'à avoir autant d'exception et de boilerplates que ses ancètres. Le test grandeur nature est juste une couteuse perte de temps.
[^] # Re: Questions
Posté par Kaane . En réponse au journal Linux from scratch face à udev. Évalué à 10.
est-ce que vous pourriez m'expliquer pourquoi systemd est-il si critiqué ?
De nombreuses raisons, mais voici les principales :
sytemd ne dialogue vraiment qu'avec dbus, si dbus ne se lance pas la machine n'a plus d'init, ou tout du moins plus un init normal, ce qui implique de faire des tests doublé pour la cohérence d'état des machines, un ou dbus démarre, un ou dbus ne démarre pas (ou pas au moment attendu). En plus le coté dialogue exclusif avec dbus nécessite l'utilisation d'un client dbus avec de gros droits si on veut pouvoir traquer un bug qui se déclare à l'init. Cette outil devra être exempt des sécurités cgroups et devra pouvoir accéder à tous les services. Ca fait une faille potentielle de plus.
systemd n'est pas compatible avec autre chose que Linux, et même pas avec autre chose que GNU/Linux à la sauce Red Hat. Bon nombre de configuration de type disques chiffrés/partition délocalisées/configuration dynamique ne sont tout simplement plus possible avec systemd qui s'attend à ce que certains éléments soient à une place bien précise avec des droits bien précis et un ordre de démarrage fixe. Notament au niveau du réseau on retrouve des défauts qui apparaissaient déjà sur networkmanager, par exemple quand il faut d'abord créer un lien VPN (PPTP, GRE ou autre) AVANT de créer une carte réseau et de lancer la couche TCP/IP. De la même façon tous les points de montage locaux sont systématiquement montés avant de lancer le moindre démon. C'est con pour Oracle par exempel qui a besoin de prendre le controle de certains points de montage en RAW et dont le montage normal ne sert qu'au debug et au cold backup. A partir de là systemd prive linux de choses importantes qu'il sait faire (et même bien faire) aujorud'hui - et il oblige en plus les devs à créer plusiseurs version de leur script d'init en fonction de la machine sur laquelle ils sont supposés s'éxecuter.
systemd pose un problème aux outils de contrôle : un truc aussi bête que apachectl devient un casse tête avec systemd, plusieurs utilisateurs peuvent controller le logiciel apache avec cet outil. Mais alors quid de systemd ? Est-ce qu'on ajoute des fonctionnalité DBus à l'outil pour lui permettre de dialoguer avec systemd pour lui dire "au fait le recharge la config" ou est-ce que l'on fait ça dans son dos en esperant qu'ils ne panique pas en voyant les processus apaches se fermer et s'ouvrir du fait d'appels à un outils qui n'est pas dans le même cgroup ? Ou alors est-ce que l'on met tout le monde dans le même cgroup, auquel cas quand on essaye de tuer un apache planté on commence par tuer l'outil qui permet d'interragir avec apache ?
(Bon pour apache les soucis sont résolus rapidement, mais pour tomcat déjà ca se complique et je ne parle pas d'Erlang ou d'autres applis distribuées)
chat échaudé craint l'eau froide : C'est pas comme si les "nouvelles API qui tuent tout" avaient une espérance de vie limité sous Linux, mais ca fait quand même 5 fois en 10 ans que l'on change complètement le paradigme d'acès au périphériques. Linux n'a pas une super réputation sur la pérénité de ses api, et pas mal de mainteneurs commencent sérieusement à en avoir marre de réinventer la roue. Devoir refaire toute la config à cause de polkit/consolekit/udev/hal qui s'enva/dbus/systemd ca amuse 5 minutes, mais là ca fait 3 ans.
Pour l'instant à moins d'une évolution très très léchée du produit par RH on est toujours obligé de gruiker les scripts pour que systemd fasse ce dont tu as besoin et pas ce qu'il veut, notamment pour les processus qui forkent dans tous les sens et qui n'ont pas de support natif de DBus. Et comme DNS, Apache et Postfix ne sont pas supposé en avoir quoi que ce soit à faire de systemd (et qu'en plus les dialogues avec systemd ne peuvent qu'avoir un impact négatif sur les perfs) ils n'auront probablement jamais de support DBus.
En fait une application unique ne peut pas faire la surveillance/le controle/le restart etc. de toutes les applis possibles et imaginables dans toutes les config possibles et imaginables - ca parait évident dit comme ça mais c'est pourtant ce qu'il essaye de faire. Donc systemd échouera, ou se pervertira jusqu'à avoir autant d'exception et de boilerplates que ses ancètres. Le test grandeur nature est juste une couteuse perte de temps.