Et si par exemple c'était dans la partie "Development Topics" slides 31 à 37 qui liste les limitations, les
améliorations et les éléments qui sont en cours d'études et de développement, il se passerait quoi ?
la même chose, à savoir que tu piges de travers l'anglais comme ça t'arrange, et que tu t'arrêtes juste à ce que tu crois être vrai ( comme montré par les autres trucs que j'ai posté )
Ben justement non j'en ai aucun.
Alors pour quoi tu nous prends pour des truffes en disant :
"il me semble que les distributions serveurs (comme Suse Entreprise ou Red Hat) envisagent très sérieusement de ne PAS passer à systemd"
Que ce soit chez Suse ou chez Red Hat ca joue à ni oui ni non. Même le support
(payant) RH est pas foutu de répondre à la question "dans RH7 ca sera systemd ou sysinit ou les deux".
Le support ne parle jamais des produits en cours de développement, et c'est pareil dans toutes les boites que j'ai fait, on laisse la relation client aux commerciaux ( ensuite, peut être que tu as bossé dans des boites différentes ). Bien que je ne soit pas juriste, je pense qu'il y a des gens qui craignent que ce genre de réponse soit "legally binding", et que ces gens sont plus juristes que toi et moi.
Le fait que ArchLinux et Mageia ait fait le pas en tant que distrib ne prouve rien au niveau de
l'utilisabilité du bigniou par des sysadmins.
Je suis sysadmin, c'est marqué sur mon contrat de travail et j'ai un serveur face à moi qui tourne avec systemd ( en mageia 2 ). Techniquement, je peux te sortir d'autres sysadmins, d'autres serveurs, ce qui fait qu'on pourras passer au pluriel.
Mais c'est sans doute pas assez rigoureux comme preuve, y a sans doute des tests pour dire "la, il arrive à s'en servir".
Le fait que Solaris soit passé à smf est la preuve qu'on peut survivre à un changement de système d'init.
Bug 774126 : si on se logue trop tôt sur une interface série le getty crashe définitivement. Il existe une
solution mais elle est trop complexe pour être backportée
Si on se logue trop tôt et qu'on utilise NIS. Et comme tu dit, c'est corrigé dans une nouvelle version systemd. Quand à backporter la feature, c'est sans doute parce que la politique est la même qu'ailleurs, à savoir juste les bugfixes, pas les features. Et la, c'est une feature ( à savoir un type de service "idle" )
Bug 779434 : pas de splash dans le boot kernel, pas de /var. Systemd refuse de monter le /var si plymouthd a un
fichier de lock qui traine dessus. COOOL
Tu as lu de travers. C'est plus "si quelqu'un a encore un file handle ouvert, alors on peut pas démonter le fs". Ce qui est le comportement standard de sysvinit et de tout les autres. Et d'après le bug, c'est plymouthd qui bloque.
Bug 780006 : Un boot pas à pas dans systemd ? Vous plaisantez bien sur. De..bug ? Jamais entendu parlé.
Un boot pas à pas dans un système prévu pour lancer les choses en même temps est ma foi un concept des plus intéressant. Pour débugguer ce genre de souci, il y a plusieurs façon. Tu peux utiliser le système de bootchart ( histoire d'avoir un graph détaillé ), tu peux avoir le graph des dépendances. En pratique, le mode pas à pas, ça va rarement servir à débloquer des soucis autre que "tel soft ne se lance pas, il faut que je le passe".
Mais le bug parle de systemd.confirm_spawn, qui va faire grosso modo la même chose que "press I for interactive mode" du boot classique d'un RH. Ensuite, visiblement, il y a un certain nombre de bugs corrigés upstream, et je ne doute pas que Frederic va tester et backporter si besoin.
Bug 780441 : L'automount NFS ne marche pas (pas chez Fedora non plus) - mais on a presque fini d'avoir une bonne
idée sur comment contourner le problème. (N.B : ce bug a une priorité P5 - none. Autmount NFS ? Ca interresse
quelqu'un ? )
C'est pas un souci de systemd, c'est un souci de nfs sur Suse, et Fedora 18 propose les unités pour nfs. Au passage, ça marche sans souci avec automount sur Mageia.
Bug 767394 : Un disque plein ? C'est un scandale ! Je me casse… (signé systemd).
Je ne peux que redire "si c'est marqué systemd quelque part, ça veut pas dire que c'est un souci de systemd". En l'occurrence, quelqu'un a rempli le systéme monté en ramfs sur un livecd ( donc avec aufs ). Donc l'oom killer a fini par tuer tout les process, en terminant par le pid 1. Comme dit dans le bug report, tu t'attends à quoi ? La backtrace est une backtrace kernel, le message est "kernel panic".
Donc sur les 5 bugs que tu donnes, il y a :
1 bug qui n'est pas un bug systemd mais le comportement normal du kernel
1 bug qui vient du script d'init nfs et d'un mauvais ordre pour les divers choses à lancer
1 bug ou la feature existe, mais possède des bugs corrigés dans la versions récentes de systemd
1 bug ou systemd se comporte comme les init classiques, due à un bug plymouthd
1 bug corrigé dans les versions récentes de systemd pour les gens qui utilisent nis, un port série et qui veulent pas attendre
Donc je compte 2 bugs déjà corrigés, 2 bug à corriger ailleurs ( nfs, plymouthd ), et 1 "why did you expect".
Ok respect, ça rends le produit totalement inutilisable d'avoir 2 bugs que le dev d'opensuse n'a pas eu le temps de backporter. En aucun cas ça va être prêt pour une release qui n'est pas encore annoncé, et en aucun cas ça va marcher sur tout les autres cas ( genre ceux ou tu as pas des ports séries avec du nis )
Je terminerais sur tes 3 boites avec sysadmins ( un échantillon donc statistiquement représentatif, et bien sur, aucunement influencé par toi, surtout au vue de ta propension à sortir des trucs crédibles sauf quand on creuse plus de 30 secondes ) et donc :
a) Il y a beaucoup de boulot et de tests à faire pour s'assurer que tout fonctionne.
Comme avec chaque version majeur. Est ce qu'ils ont eu des tonnes de boulot avec upstart sur les RHEL 6 ? J'ai loupé les émeutes qu'il y a du y avoir à ce sujet mais bon, c'est la même chose non ?
Sinon, quand tu payes la souscription RHEL ou SLES, c'est aussi pour que le distributeur fasse les tests ( sauf bien sur pour les horreurs homegrowns dont tu as parlé la dernière fois ).
b) Certaines choses (certains fs chiffrés, demande de mot de passe à l'init par service, templates etc.) ne sont
pas possible avec systemd.
En effet, c'est à dessein pour certains. Le mot de passe à l'init, une riche idée quand le systéme est sequentielle car ton serveur se bloque en attendant de rentrer le mot de passe, c'est pas du tout fragile au possible. Je pense au passage que c'était pas possible non plus avec upstart qui dans mon souvenir lance les trucs en parallèle. Quand aux templates, j'ai deja du dire que ç'est prévu par systemd, et la dernière fois, tu as sorti un exemple super compliqué pour dire "regarde, dans ce cas totalement trop compliqué, je sais pas comment faire mais j'ai pas le droit d'en dire plus, donc ça invalide tout"
c) Systemd n'est pas fini/normalisé et du coup même si ils trouvent des parades aujourd'hui
rien ne prouve qu'elles seront encore valables dans dix jours (spéciale dédicace udev)
Formidable ça. Parce que upstart ou l'init classique sysinit, c'était normalisé ? Le seule chose vraie qu'on peut dire, c'est que sysvinit était "fini" dans le sens ou il y avait plus d'évolution dessus. Normalisé, systemd suit la LSB, donc les scripts d'init doivent marcher encore. Bie sur, tu va trouver sans doute des cas de scripts hors lsb qui ne marche pas, et dire "bah ça marche pas".
[^] # Re: Pourquoi du binaire
Posté par Misc (site web personnel) . En réponse au journal Documentation du format du Journal. Évalué à 8.
la même chose, à savoir que tu piges de travers l'anglais comme ça t'arrange, et que tu t'arrêtes juste à ce que tu crois être vrai ( comme montré par les autres trucs que j'ai posté )
Alors pour quoi tu nous prends pour des truffes en disant :
"il me semble que les distributions serveurs (comme Suse Entreprise ou Red Hat) envisagent très sérieusement de ne PAS passer à systemd"
Le support ne parle jamais des produits en cours de développement, et c'est pareil dans toutes les boites que j'ai fait, on laisse la relation client aux commerciaux ( ensuite, peut être que tu as bossé dans des boites différentes ). Bien que je ne soit pas juriste, je pense qu'il y a des gens qui craignent que ce genre de réponse soit "legally binding", et que ces gens sont plus juristes que toi et moi.
Je suis sysadmin, c'est marqué sur mon contrat de travail et j'ai un serveur face à moi qui tourne avec systemd ( en mageia 2 ). Techniquement, je peux te sortir d'autres sysadmins, d'autres serveurs, ce qui fait qu'on pourras passer au pluriel.
Mais c'est sans doute pas assez rigoureux comme preuve, y a sans doute des tests pour dire "la, il arrive à s'en servir".
Le fait que Solaris soit passé à smf est la preuve qu'on peut survivre à un changement de système d'init.
Si on se logue trop tôt et qu'on utilise NIS. Et comme tu dit, c'est corrigé dans une nouvelle version systemd. Quand à backporter la feature, c'est sans doute parce que la politique est la même qu'ailleurs, à savoir juste les bugfixes, pas les features. Et la, c'est une feature ( à savoir un type de service "idle" )
Tu as lu de travers. C'est plus "si quelqu'un a encore un file handle ouvert, alors on peut pas démonter le fs". Ce qui est le comportement standard de sysvinit et de tout les autres. Et d'après le bug, c'est plymouthd qui bloque.
Un boot pas à pas dans un système prévu pour lancer les choses en même temps est ma foi un concept des plus intéressant. Pour débugguer ce genre de souci, il y a plusieurs façon. Tu peux utiliser le système de bootchart ( histoire d'avoir un graph détaillé ), tu peux avoir le graph des dépendances. En pratique, le mode pas à pas, ça va rarement servir à débloquer des soucis autre que "tel soft ne se lance pas, il faut que je le passe".
Mais le bug parle de systemd.confirm_spawn, qui va faire grosso modo la même chose que "press I for interactive mode" du boot classique d'un RH. Ensuite, visiblement, il y a un certain nombre de bugs corrigés upstream, et je ne doute pas que Frederic va tester et backporter si besoin.
C'est pas un souci de systemd, c'est un souci de nfs sur Suse, et Fedora 18 propose les unités pour nfs. Au passage, ça marche sans souci avec automount sur Mageia.
Je ne peux que redire "si c'est marqué systemd quelque part, ça veut pas dire que c'est un souci de systemd". En l'occurrence, quelqu'un a rempli le systéme monté en ramfs sur un livecd ( donc avec aufs ). Donc l'oom killer a fini par tuer tout les process, en terminant par le pid 1. Comme dit dans le bug report, tu t'attends à quoi ? La backtrace est une backtrace kernel, le message est "kernel panic".
Donc sur les 5 bugs que tu donnes, il y a :
1 bug qui n'est pas un bug systemd mais le comportement normal du kernel
1 bug qui vient du script d'init nfs et d'un mauvais ordre pour les divers choses à lancer
1 bug ou la feature existe, mais possède des bugs corrigés dans la versions récentes de systemd
1 bug ou systemd se comporte comme les init classiques, due à un bug plymouthd
1 bug corrigé dans les versions récentes de systemd pour les gens qui utilisent nis, un port série et qui veulent pas attendre
Donc je compte 2 bugs déjà corrigés, 2 bug à corriger ailleurs ( nfs, plymouthd ), et 1 "why did you expect".
Ok respect, ça rends le produit totalement inutilisable d'avoir 2 bugs que le dev d'opensuse n'a pas eu le temps de backporter. En aucun cas ça va être prêt pour une release qui n'est pas encore annoncé, et en aucun cas ça va marcher sur tout les autres cas ( genre ceux ou tu as pas des ports séries avec du nis )
Je terminerais sur tes 3 boites avec sysadmins ( un échantillon donc statistiquement représentatif, et bien sur, aucunement influencé par toi, surtout au vue de ta propension à sortir des trucs crédibles sauf quand on creuse plus de 30 secondes ) et donc :
Comme avec chaque version majeur. Est ce qu'ils ont eu des tonnes de boulot avec upstart sur les RHEL 6 ? J'ai loupé les émeutes qu'il y a du y avoir à ce sujet mais bon, c'est la même chose non ?
Sinon, quand tu payes la souscription RHEL ou SLES, c'est aussi pour que le distributeur fasse les tests ( sauf bien sur pour les horreurs homegrowns dont tu as parlé la dernière fois ).
En effet, c'est à dessein pour certains. Le mot de passe à l'init, une riche idée quand le systéme est sequentielle car ton serveur se bloque en attendant de rentrer le mot de passe, c'est pas du tout fragile au possible. Je pense au passage que c'était pas possible non plus avec upstart qui dans mon souvenir lance les trucs en parallèle. Quand aux templates, j'ai deja du dire que ç'est prévu par systemd, et la dernière fois, tu as sorti un exemple super compliqué pour dire "regarde, dans ce cas totalement trop compliqué, je sais pas comment faire mais j'ai pas le droit d'en dire plus, donc ça invalide tout"
Formidable ça. Parce que upstart ou l'init classique sysinit, c'était normalisé ? Le seule chose vraie qu'on peut dire, c'est que sysvinit était "fini" dans le sens ou il y avait plus d'évolution dessus. Normalisé, systemd suit la LSB, donc les scripts d'init doivent marcher encore. Bie sur, tu va trouver sans doute des cas de scripts hors lsb qui ne marche pas, et dire "bah ça marche pas".