Quelle est la valeur d'une paire de soucis? Peanuts
Ce que l'auteur pense importe peu. Vous avez peur de dire ce que vous en pensez ?
Vous êtes proFedora donc vous manquez d'objectivité car vous défendrez forcément systemd
upstart c'est de l'ubuntu donc forcément vous ne l'aimerez pas…
Donc récapitulons. J'ai une opinion donc je manque d'objectivité ( c'est grosso modo la définition, mais bon, passons ). Je donne donc pour éviter de tomber dans ce travers un lien de quelqu'un que je connais pas, mais d'un coup j'aurais peur de dire ce que j'ai déjà dit 15 fois sur linuxfr.
Certes. Et au final, quoi que je dise, je suis pro fedora, donc forcement, je vomis ce que fait Ubuntu. Parce que c'est bien connu, quand on utilise une distribution, ça retire tout sens critique, donc pas besoin de donner d'argument.
Au lieu de m'éterniser sur des arguments stériles et des attaques ad hominem, regardons de plus prêt ce que l'auteur de l'article dit :
il donne également l'exemple de la modification de la config d'un systéme, ou pareil, le fait de modifier le fichier fait qu'il risque de passer à coté d'une modification, car c'est plus proche d'un script. Pareil, il mets la correction de ce souci comme avantage de systemd. Lien : http://utcc.utoronto.ca/~cks/space/blog/linux/UpstartDependencyProblem
Donc voila 4 problèmes liés à l'architecture d'upstart ( ie, le fait d'avoir un fichier de config qui est en fait un script, et le fait d'utiliser ptrace pour suivre les processus ), corrigé par le design de systemd, à savoir avoir des fichiers au format .ini, ce qui permet de mettre des priorités sur les directives qui découlent d'un ordre de lecture prétabli, et l'usage des cgroups, pour gérer les groupes de processus. Cgroups déjà à la base de lxc, donc relativement étanche.
Exemple typique de manque d'objectivité:
Le soucis est subtile , donc pas vraiment identifié…
Une affirmation pertinente serait de préciser LE soucis
Quand je dit subtile, je veux dire par la difficilement identifiable. Par exemple, se connecter en ssh, et relancer un serveur web et voir plus tard que tout d'un coup, ton cgi qui appelle la commande 'sort' merdouille parce que la variable LANG n'a pas été nettoyé ( ie, LANG=FR_fr est passé au script, puis à apache, puis à ton cgi, puis à 'sort' qui va trier les caractères diacritiques d'une façon différente en fonction de la locale ). Ou voir qu'en fonction de comment est lancé ton soft, tu as un autre format de date dans les logs, car il reprends LC_ALL et LC_TIME. Bien sur, si on était sur d'avoir toujours le même environnement clean, ça n'arriverais pas ( khofhttp://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRestartEnvironmentkhof )
Gentoo est connu comme très solide et très sérieux.
ah ah ah
Pardon.
J'ai rien contre Gentoo, j'ai un serveur sous Gentoo chez OVh, et je dirais même que je connais des gentooistes ( bien la preuve que je suis pas raciste ). Mais sérieux et solide n'est pas forcément ce qui me vient à l'esprit. J'aurais plutôt dit flexible et adaptatif.
Sérieux, pour moi, ça implique par exemple un suivi des soucis de sécurité et pendant un bon bout de temps, il n'y plus eu d'alertes de sécurité (cf http://www.gentoo.org/security/en/glsa/index.xml entre janvier 2010 et mai 2010 ).
Solide, je dirais que c'est plus la personne qui décide de pas abuser de l'adaptabilité. Il faut bien voir qu'en pratique et en fonction des choix de l'admin, chacun a un système différent. L'utilisateur est le premier, dernier et seul personne à faire la QA de son système. ( bon, pas exactement, mais j'ai toujours voulu caser la formule ). Les paquets passent de masked a unmasked sur la base des retours des gens, ce qui garantit des tests minimums, mais les retours sont se font dans des environnements différents. Et c'est une approche différente d'une debian ou d'une autre distro binaire, ou tout le monde a les mêmes binaires ce qui fait que si ça marche chez X personnes, alors il y a moins de raison que ça foire ailleurs. Alors que gentoo, avec les use flags, etc…
Et comme il y a pas de mises à jours de sécu au sens "mise à jour minimal" avec la QA qui va avec, la solidité n'est pas une chose que j'estime acquise, bien que je n'ai pas eu à me plaindre personnellement si souvent et que c'est suffisant pour ce que j'en fait.
Openrc, qui a quand même eu 10 ans pour se faire adopter, semble faire un revival. Bien sur, personne ne va dire que openrc, il supporte le boot en parallèle avec des bugs compliqué à reproduire ( https://bugs.gentoo.org/show_bug.cgi?id=391945 ).
it apparently does per-user fair share scheduling by default (but I haven't had a chance to run systemd in a
situation where I could really see this in action)
En gros donc, vous nous vantez les mérites de systemd comme étant une révolution, mais même ce monsieur n'arrive
pas à réaliser une telle opération qui est théoriquement facile puisque systemd est une révolution.
Je n'ai pas dit "révolution", j'ai laissé mon pull noir à col roulé au placard. Et j'ai du mal à saisir. L'auteur de l'article n'a pas eu de situation ou le "fair share scheduling", traduisons par "partage équitable de l'ordonnanceur" a pu s'appliquer, donc ça rends systemd compliqué ? Si ses serveurs ne sont pas chargé ras la gueule au point d'en avoir besoin, ou est le souci ?
Pour info, ce dont il parle est détaillé la : http://lwn.net/Articles/415740/ , avec la réponse de lennart la : http://lwn.net/Articles/415756/. Si les gens passent pas leur temps à mettre leur bécane sur les genoux à grand coup de compile kernel pour constater si systemd fait un truc, c'est la faute de systemd ?
is mostly written in C […] XML [15% du code]
Pour info, ce que l'auteur a voulu dire, c'est que contrairement à smf, l'init de solaris, systemd n'utilise pas de xml pour sa config donc l'admin n'a pas à interagir avec. Ensuite, la doc est en docbook ( un format de publication en xml ), et en effet, 15% du contenu du tarball, c'est de la doc en xml.
Mais c'était bien tenté.
Tout le monde est d'avis que le système [init] fonctionne correctement depuis 40 ans.
Pas moi. Ni les gens de chez Sun, vu qu'ils ont refait le système avec SMF. Ni les gens d'Ubuntu ou de Chrome OS, vu qu'ils ont upstart ( ou RHEL 6, ou Maemo ). D'ailleurs pas les gens de Gentoo, vu qu'ils ont fait openrc. En fait, Apple aussi a refait son système d'init il y a 3/4 versions. Donc oui, si on retire tout ça, tout le monde pense que ça marche.
Enfin pas ceux qui ont fait runit ou initng non plus. Ni les gens de FreeBSD qui ont proposé un portage de launchd dans un Google Summer of Code.
Enfin donc, à part tout les gens qui sont tellement d'avis que ça fonctionne correctement qu'ils se sont dit qu'il faut le remplacer, ouais, tout les autres pensent que ça marche.
Enfin si on retire tout ceux qui ont choisi systemd, comme arch, opensuse, mandriva, fedora mageia, ou des boites comme intel ou rackspace ( vu que intel bosse dessus, rackspace bosse sur journald ), oui, tout les autres pensent sans doute que ça marche comme il faut.
Mais bon, je suppose que juste donner des noms, ça ne va convaincre personne, donc je vais détailler. Déjà, quand tu dit "le systeme d'init marche depuis 40 ans", tu veux sans doute parler de sysvinit, et donc depuis 30 ans. Bon, pas grave, 10 ans, c'est presque rien. Le système des premiers unix était sans doute un chouia plus frustre, et je me demande si à l'époque, les gens ont ralés devant la complexité d'avoir gasp, une couche d'indirection de plus.
Alors déjà, si ça marche bien, pourquoi toutes les distros ont rajouté le support des tags LSB pour l'ordre des scripts si le format de base est si bien ? Non, pas la peine de répondre, c'est parce que c'est moisi de devoir choisir à la main l'ordre. Et parce qu'il y a pas vraiment de format, juste des conventions, comme le fait de faire un printf, le fait d'avoir X ordres. Je vais pas parler des codes de retour des initscripts, je risquerais de devenir grossier.
Ensuite, non ça me marche pas bien. Par exemple, bind est le premier exemple que je donne à chaque fois. Bind utilise la commande rdnc pour signaler au processus principal qu'il doit s’arrêter. Sauf que comme c'est une communication unidirectionnel, en fonction de la charge de la machine, tu ne sais pas si bind est coupé ou pas au moment ou la commande rends la main. On pourrait croire naïvement que ça n'a pas d'importance, sauf que si tu fais un stop et un start ( ce qui est quand même la façon la plus universelle de faire restart ), et ben parfois, bind ne se relance pas, car l'autre n'est pas mort. Bien sur, ça dépend de la machine et de sa charge. Et se dire qu'on est passé d'un coup en fonctionnement asynchrone sans le savoir, ça montre bien qu'il y a des soucis.
Les distros gèrent ça de différentes façon. Debian fait une boucle avec un kill -0 ( donc n'envoie pas de signal fatal ) et attends que le process meurt, donc que le kill échoue. Ce qui est moche pour le cas rare ou le PID est recyclé assez vite ( ie, il y a une race condition ), car le script attendrait à l'infini ou presque.
Mandriva fait ça avec un sleep 5, ce qui tout aussi un hack.
Systemd, il gère ça en suivant tout les process du groupe. Ie, quand ils sont morts, il le sait.
Le deuxième exemple, c'est mon ami Sympa. Sympa, c'est vachement bien, plus souple de mailman sauf qu'il y a un léger souci. Quand tu le connectes à postgresql ( ce que l'équipe de sysadmin de Mageia a fait ), si la base de données n'est pas disponible, il attends. Il attends pas en tache de fond. Il attends et le script d'init ( une horreur qui lance 5 services d'un coup ) se bloque. Donc si ta base se lance après par la magie des scripts, ton serveur se bloque au boot. En fait, c'est aussi amusant si postgresql mets du temps à mettre son socket à disposition pour une raison X ou Y, car même en étant lancé avant, sympa bloque le boot. Alors bien sur, une fois que tu as pigé le souci, ç'est facile à corriger. D'ailleurs, ça a été corrigé upstream d’après le packageur debian avec qui j'ai eu le temps d'échanger sur le sujet.
Systemd, il gère ça en lançant tout en même temps, et en s'en foutant d'un process qui bloque.
Alors le 3eme exemple, c'est Apache. Apache, c'est un soft cool, ça gère les processus pour toi. Sauf que voila, parfois, y a des processus qui partent en vrille ( ce qui arrive quand on embarque des saletés dedans comme php, ou des cgis ), et parfois, pareil que bind, ça mets du temps à mourir. Comme le process principal tot ou tard meurt, il reste parfois des orphelins. Et c'est coriace ce genre de bestiole, car faut que l'admin vienne à la main faire le ménage. Bien sur, pareil que bind, ça arrive pas toujours, même rarement. Il faut bien tomber sur des circonstances aggravantes pour que ça se produise.
Mais bon, c'est pareil, c'est entièrement du à sysV. Parce qu'avec les cgroups, tu peux faire du kill(9) à tout va après un temps.
Ensuite, des gens vont te dire que la pauvreté de sysV implique de dupliquer le code pour passer un soft en daemon dans chaque soft, que statistiquement tout le monde ne le fait pas tout ce qu'il faut comme il faut ( à savoir se rattacher à un groupe de process, faire un chdir('/'), fermer tout les descripteurs de fichiers, faire un double fork, et sans doute des trucs que j'oublie ) et que du coup, ça cause des soucis
Avec sans doute une petite biére, ils vont continuer pour expliquer qu'il y a des problématiques à la con entre setuid, setgid ( l'ordre par exemple, ou le fait de fait un initgroup avec setgid ), et que même les meilleurs oublient, ou te parler de cas ou un init script s'est vautré sur un fichier de pid non effacé du à un reboot intempestif de la machine.
D'autres gens vont te répondre que systemd mutualise tout ça et que le code écrit une fois utilisé pour 50 softs est plus sur que le code écrit 50 fois par 50 personnes. Ces autres gens vont aussi te dire que systemd va gérer /var/run sur un tmpfs ( http://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html ), ce qui est "reboot intempestif friendly".
Mais bon, je suppose que tout ces gens, tu va sans doute dire que leur objectivité est impossible, qu'ils ont tort parce que toi, tu as eu aucun problème donc ça prouve bien que ça n'existe pas ?
[^] # Re: Et pour en remettre une couche
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 10.
Donc récapitulons. J'ai une opinion donc je manque d'objectivité ( c'est grosso modo la définition, mais bon, passons ). Je donne donc pour éviter de tomber dans ce travers un lien de quelqu'un que je connais pas, mais d'un coup j'aurais peur de dire ce que j'ai déjà dit 15 fois sur linuxfr.
Certes. Et au final, quoi que je dise, je suis pro fedora, donc forcement, je vomis ce que fait Ubuntu. Parce que c'est bien connu, quand on utilise une distribution, ça retire tout sens critique, donc pas besoin de donner d'argument.
Au lieu de m'éterniser sur des arguments stériles et des attaques ad hominem, regardons de plus prêt ce que l'auteur de l'article dit :
Rajoutons donc ce que je sais à savoir que upstart utilise la commande ptrace pour suivre les process, et que curieusement, ça passe pas tout le temps. Comme je ne veux pas donner dans le FUD, il y a 2 liens :
https://bugs.launchpad.net/upstart/+bug/406397
https://bugs.launchpad.net/upstart/+bug/703800
Donc voila 4 problèmes liés à l'architecture d'upstart ( ie, le fait d'avoir un fichier de config qui est en fait un script, et le fait d'utiliser ptrace pour suivre les processus ), corrigé par le design de systemd, à savoir avoir des fichiers au format .ini, ce qui permet de mettre des priorités sur les directives qui découlent d'un ordre de lecture prétabli, et l'usage des cgroups, pour gérer les groupes de processus. Cgroups déjà à la base de lxc, donc relativement étanche.
Quand je dit subtile, je veux dire par la difficilement identifiable. Par exemple, se connecter en ssh, et relancer un serveur web et voir plus tard que tout d'un coup, ton cgi qui appelle la commande 'sort' merdouille parce que la variable LANG n'a pas été nettoyé ( ie, LANG=FR_fr est passé au script, puis à apache, puis à ton cgi, puis à 'sort' qui va trier les caractères diacritiques d'une façon différente en fonction de la locale ). Ou voir qu'en fonction de comment est lancé ton soft, tu as un autre format de date dans les logs, car il reprends LC_ALL et LC_TIME. Bien sur, si on était sur d'avoir toujours le même environnement clean, ça n'arriverais pas ( khof http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRestartEnvironment khof )
J'ai rien contre Gentoo, j'ai un serveur sous Gentoo chez OVh, et je dirais même que je connais des gentooistes ( bien la preuve que je suis pas raciste ). Mais sérieux et solide n'est pas forcément ce qui me vient à l'esprit. J'aurais plutôt dit flexible et adaptatif.
Sérieux, pour moi, ça implique par exemple un suivi des soucis de sécurité et pendant un bon bout de temps, il n'y plus eu d'alertes de sécurité (cf http://www.gentoo.org/security/en/glsa/index.xml entre janvier 2010 et mai 2010 ).
Solide, je dirais que c'est plus la personne qui décide de pas abuser de l'adaptabilité. Il faut bien voir qu'en pratique et en fonction des choix de l'admin, chacun a un système différent. L'utilisateur est le premier, dernier et seul personne à faire la QA de son système. ( bon, pas exactement, mais j'ai toujours voulu caser la formule ). Les paquets passent de masked a unmasked sur la base des retours des gens, ce qui garantit des tests minimums, mais les retours sont se font dans des environnements différents. Et c'est une approche différente d'une debian ou d'une autre distro binaire, ou tout le monde a les mêmes binaires ce qui fait que si ça marche chez X personnes, alors il y a moins de raison que ça foire ailleurs. Alors que gentoo, avec les use flags, etc…
Et comme il y a pas de mises à jours de sécu au sens "mise à jour minimal" avec la QA qui va avec, la solidité n'est pas une chose que j'estime acquise, bien que je n'ai pas eu à me plaindre personnellement si souvent et que c'est suffisant pour ce que j'en fait.
Openrc, qui a quand même eu 10 ans pour se faire adopter, semble faire un revival. Bien sur, personne ne va dire que openrc, il supporte le boot en parallèle avec des bugs compliqué à reproduire ( https://bugs.gentoo.org/show_bug.cgi?id=391945 ).
Je n'ai pas dit "révolution", j'ai laissé mon pull noir à col roulé au placard. Et j'ai du mal à saisir. L'auteur de l'article n'a pas eu de situation ou le "fair share scheduling", traduisons par "partage équitable de l'ordonnanceur" a pu s'appliquer, donc ça rends systemd compliqué ? Si ses serveurs ne sont pas chargé ras la gueule au point d'en avoir besoin, ou est le souci ?
Pour info, ce dont il parle est détaillé la : http://lwn.net/Articles/415740/ , avec la réponse de lennart la : http://lwn.net/Articles/415756/. Si les gens passent pas leur temps à mettre leur bécane sur les genoux à grand coup de compile kernel pour constater si systemd fait un truc, c'est la faute de systemd ?
Pour info, ce que l'auteur a voulu dire, c'est que contrairement à smf, l'init de solaris, systemd n'utilise pas de xml pour sa config donc l'admin n'a pas à interagir avec. Ensuite, la doc est en docbook ( un format de publication en xml ), et en effet, 15% du contenu du tarball, c'est de la doc en xml.
Mais c'était bien tenté.
Pas moi. Ni les gens de chez Sun, vu qu'ils ont refait le système avec SMF. Ni les gens d'Ubuntu ou de Chrome OS, vu qu'ils ont upstart ( ou RHEL 6, ou Maemo ). D'ailleurs pas les gens de Gentoo, vu qu'ils ont fait openrc. En fait, Apple aussi a refait son système d'init il y a 3/4 versions. Donc oui, si on retire tout ça, tout le monde pense que ça marche.
Enfin pas ceux qui ont fait runit ou initng non plus. Ni les gens de FreeBSD qui ont proposé un portage de launchd dans un Google Summer of Code.
Enfin donc, à part tout les gens qui sont tellement d'avis que ça fonctionne correctement qu'ils se sont dit qu'il faut le remplacer, ouais, tout les autres pensent que ça marche.
Enfin si on retire tout ceux qui ont choisi systemd, comme arch, opensuse, mandriva, fedora mageia, ou des boites comme intel ou rackspace ( vu que intel bosse dessus, rackspace bosse sur journald ), oui, tout les autres pensent sans doute que ça marche comme il faut.
Mais bon, je suppose que juste donner des noms, ça ne va convaincre personne, donc je vais détailler. Déjà, quand tu dit "le systeme d'init marche depuis 40 ans", tu veux sans doute parler de sysvinit, et donc depuis 30 ans. Bon, pas grave, 10 ans, c'est presque rien. Le système des premiers unix était sans doute un chouia plus frustre, et je me demande si à l'époque, les gens ont ralés devant la complexité d'avoir gasp, une couche d'indirection de plus.
Alors déjà, si ça marche bien, pourquoi toutes les distros ont rajouté le support des tags LSB pour l'ordre des scripts si le format de base est si bien ? Non, pas la peine de répondre, c'est parce que c'est moisi de devoir choisir à la main l'ordre. Et parce qu'il y a pas vraiment de format, juste des conventions, comme le fait de faire un printf, le fait d'avoir X ordres. Je vais pas parler des codes de retour des initscripts, je risquerais de devenir grossier.
Ensuite, non ça me marche pas bien. Par exemple, bind est le premier exemple que je donne à chaque fois. Bind utilise la commande rdnc pour signaler au processus principal qu'il doit s’arrêter. Sauf que comme c'est une communication unidirectionnel, en fonction de la charge de la machine, tu ne sais pas si bind est coupé ou pas au moment ou la commande rends la main. On pourrait croire naïvement que ça n'a pas d'importance, sauf que si tu fais un stop et un start ( ce qui est quand même la façon la plus universelle de faire restart ), et ben parfois, bind ne se relance pas, car l'autre n'est pas mort. Bien sur, ça dépend de la machine et de sa charge. Et se dire qu'on est passé d'un coup en fonctionnement asynchrone sans le savoir, ça montre bien qu'il y a des soucis.
Les distros gèrent ça de différentes façon. Debian fait une boucle avec un kill -0 ( donc n'envoie pas de signal fatal ) et attends que le process meurt, donc que le kill échoue. Ce qui est moche pour le cas rare ou le PID est recyclé assez vite ( ie, il y a une race condition ), car le script attendrait à l'infini ou presque.
Mandriva fait ça avec un sleep 5, ce qui tout aussi un hack.
Systemd, il gère ça en suivant tout les process du groupe. Ie, quand ils sont morts, il le sait.
Le deuxième exemple, c'est mon ami Sympa. Sympa, c'est vachement bien, plus souple de mailman sauf qu'il y a un léger souci. Quand tu le connectes à postgresql ( ce que l'équipe de sysadmin de Mageia a fait ), si la base de données n'est pas disponible, il attends. Il attends pas en tache de fond. Il attends et le script d'init ( une horreur qui lance 5 services d'un coup ) se bloque. Donc si ta base se lance après par la magie des scripts, ton serveur se bloque au boot. En fait, c'est aussi amusant si postgresql mets du temps à mettre son socket à disposition pour une raison X ou Y, car même en étant lancé avant, sympa bloque le boot. Alors bien sur, une fois que tu as pigé le souci, ç'est facile à corriger. D'ailleurs, ça a été corrigé upstream d’après le packageur debian avec qui j'ai eu le temps d'échanger sur le sujet.
Systemd, il gère ça en lançant tout en même temps, et en s'en foutant d'un process qui bloque.
Alors le 3eme exemple, c'est Apache. Apache, c'est un soft cool, ça gère les processus pour toi. Sauf que voila, parfois, y a des processus qui partent en vrille ( ce qui arrive quand on embarque des saletés dedans comme php, ou des cgis ), et parfois, pareil que bind, ça mets du temps à mourir. Comme le process principal tot ou tard meurt, il reste parfois des orphelins. Et c'est coriace ce genre de bestiole, car faut que l'admin vienne à la main faire le ménage. Bien sur, pareil que bind, ça arrive pas toujours, même rarement. Il faut bien tomber sur des circonstances aggravantes pour que ça se produise.
Mais bon, c'est pareil, c'est entièrement du à sysV. Parce qu'avec les cgroups, tu peux faire du kill(9) à tout va après un temps.
Ensuite, des gens vont te dire que la pauvreté de sysV implique de dupliquer le code pour passer un soft en daemon dans chaque soft, que statistiquement tout le monde ne le fait pas tout ce qu'il faut comme il faut ( à savoir se rattacher à un groupe de process, faire un chdir('/'), fermer tout les descripteurs de fichiers, faire un double fork, et sans doute des trucs que j'oublie ) et que du coup, ça cause des soucis
Avec sans doute une petite biére, ils vont continuer pour expliquer qu'il y a des problématiques à la con entre setuid, setgid ( l'ordre par exemple, ou le fait de fait un initgroup avec setgid ), et que même les meilleurs oublient, ou te parler de cas ou un init script s'est vautré sur un fichier de pid non effacé du à un reboot intempestif de la machine.
D'autres gens vont te répondre que systemd mutualise tout ça et que le code écrit une fois utilisé pour 50 softs est plus sur que le code écrit 50 fois par 50 personnes. Ces autres gens vont aussi te dire que systemd va gérer /var/run sur un tmpfs ( http://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html ), ce qui est "reboot intempestif friendly".
Mais bon, je suppose que tout ces gens, tu va sans doute dire que leur objectivité est impossible, qu'ils ont tort parce que toi, tu as eu aucun problème donc ça prouve bien que ça n'existe pas ?