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" _
C'est dans leur distribs betas, c'est dans le code des paquets mais ça n'est officiel nul part. Comment tu interprètes toi qu'un papier qui dit que Suse Entreprise Server utilisera systemd soit retiré ?
Le truc c'est que soit ils ont décidé de mettre systemd quoi qu'il arrive, mais qu'ils tiennent absolument à nous faire la surprise (ce que tu as l'air de penser), soit ils ne sont pas sur de mettre 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,
Et dans la plupart des cas j'en ai rien à faire. Mais dans le cas présent si il faut porter tous les scripts d'init custom j'aimerai pouvoir commencer en avance. Maintenant je ne suis pas categoriste, si le support n'a pas le droit de répondre, je prend la réponse de n'importe qui d'officiel à la place. Seulement cette réponse (à l'heure actuelle) je ne l'ai pas.
Le fait que Solaris soit passé à smf est la preuve qu'on peut survivre à un changement de système d'init.
J'ai aucun problème avec un changement d'init. J'ai un problème majeur avec systemd. SMF est une réussite et si on pouvait avoir un truc pareil sous Linux je ferais des bonds de joie. Les points forts de SMF sont :
- Tout un système basé quasi exclusivement sur les templates : tous les services sont des templates, et on peut facilement créer et détruire des instances à la volée en changeant les paramètres de configuration ou en dupliquant une instance existante.
- Des dépendances ultra-réduites. Pas besoin de ramener une pléthore d'outils pour que ca marche.
- Un grand respect de l'existant : les scripts de rc.d/* continuent d'être executés. inittab est toujours parsé etc.
- Un système turing complet avec des vrais outils pour manipuler l'environnement d’exécution des services aussi bien avant le démarrage que pendant l’exécution.
Et pléthore d'autres trucs qui font cruellement défaut à systemd.
Si on se logue trop tôt et qu'on utilise NIS. Et comme tu dit, c'est corrigé dans une nouvelle version systemd.
Le problème n'est pas là. Le problème est comment une interaction de ce type peut-elle tromper l'init et le faire se comporter de façon nocive pour le système ? Un getty crashe (ca peut arriver), ben on le relance.
Ce qui est le comportement standard de sysvinit et de tout les autres. Et d'après le bug, c'est plymouthd qui bloque.
Une fois de plus le problème n'est pas la. Que /var ne se démonte pas parcequ'il est locké OK, mais pourquoi au reboot systemd devient-il incapable de monter /var ? Je n'ai jamais eu d'erreur de type 'ah non, il y a un fichier de lock alors j'interdis le montage' sur sysinit ou sur bsdinit. Comment un fichier à la con peut-il empêcher /var de monter ?
Que le fichier vienne de plymouth on s'en fout.
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.
Au hasard parce que justement comme le système n'est pas prédictif, j'aimerais bien pouvoir lancer B avant A pour voir ce qui se passe. Par exemple si j'ai un bug qui se produit une fois sur 5 ou 6 et que je pense que c'est la fois ou le service TUTU se lance avant le service TOTO qui est normalement toujours premier à s'executer. Là pour faire ce genre de tests il faut que je fasse dépendre artificiellement TOTO de TUTU (et bien entendu que je remette les trucs dans le bon ordre si c'est pas ça). Si j'ai trois ou quatre hypothèses je vais me marrer.
C'est pas un souci de systemd, c'est un souci de nfs sur Suse, et Fedora 18 propose les unités pour nfs.
Non. C'est bien un manque de systemd (pas un problème à proprement parlé, mais un comportement inattendu) que l'on peut contourner. Les sockets virtuels foutent la grouille entre les différents process de NFS et comme automount part très vite on est obligé de broder un peu pour que ypbind et autofs soient actifs et en forme pour de vrai au moment ou automount vient les chercher.
Comme dit dans le bug report, tu t'attends à quoi ?
Tu es en train d'insinuer que c'est un comportement normal de tuer l'init quand un disque ram est plein ? Comme dit le bug report une ligne plus bas, je m'attends plutôt à ce que l'on arrive sur un refus genre "disque plein" avec des retry et des purges (enfin comme sur n'importe quel autre fs quoi).
Donc je compte 2 bugs déjà corrigés, 2 bug à corriger ailleurs ( nfs, plymouthd ), et 1 "why did you expect".
Donc bien 5 bugs, des trucs qui peuvent se produire et qui explosent l'init.
Et les corrections ne sont pas coté systemd (genre ah oui, dans ce cas dégénéré là ca empêche l'init - c'est embêtant quand même) mais coté des outils. Genre ok le logiciel de haut niveau TOTO a planté l'init, mais c'est de sa faute il a pas fait les appels comme il faut et c'est corrigé dans la version 4.2 du logiciel TOTO.)
Le problème est que le logiciel de haut niveau TOTO ne devrait pas pouvoir planter l'init. Pas du tout. Bordel c'est l'init ! Ca doit être bétonné.
Comme avec chaque version majeur. Est ce qu'ils ont eu des tonnes de boulot avec upstart sur les RHEL 6 ?
Grosso modo upstart ca a foutu la grouille dans les configs TTY à la con et les runlevels custom, mais c'était pas bien méchant au final. Ne serait-ce que parce qu'on avait toujours les scripts et l'environnement.
Sinon, quand tu payes la souscription RHEL ou SLES, c'est aussi pour que le distributeur fasse les tests
Le distributeur il t'aide en cas de pépin et il peut débugguer des trucs pas évident. Mais il n'a pas un clone de ton install chez lui. Donc pour faire les tests…
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.
Les trucs qui dépendent du mot de passe sont nécessairement bloqués (en fait c'est même le but d'un mot de passe) - Les trucs qui ne dépendent pas du mot de passe continuent. Quand il y a plusieurs mots de passe, pour s'y retrouver on affiche un texte explicatif (Genre veuillez rentrer le mot de passe pour le certificat truc de l'instance apache www.example.com )
Je pense au passage que c'était pas possible non plus avec upstart qui dans mon souvenir lance les trucs en parallèle.
Si si, ça marche très bien. Parce que upstart execute des scripts et sait mettre les demande d'interaction utilisateur à la queue leu leu.
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é
Un truc super compliqué : une variable d'environnement dont le contenu n'est pas fixe.
Un autre truc super compliqué : le résultat de l’exécution d'un autre service.
Heureusement ça arrive rarement les service qui donne des résultats ou les variables d'environnement qui changent.
Formidable ça. Parce que upstart ou l'init classique sysinit, c'était normalisé ?
Non mais c'était turing complet. Donc on pouvait TOUJOURS trouver une solution ou un contournement.
Bie sur, tu va trouver sans doute des cas de scripts hors lsb qui ne marche pas, et dire "bah ça marche pas".
Il y a des scripts d'init full LSB qui ne marchent pas. Pour les partitions chiffrées notamment.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 4.
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" _
C'est dans leur distribs betas, c'est dans le code des paquets mais ça n'est officiel nul part. Comment tu interprètes toi qu'un papier qui dit que Suse Entreprise Server utilisera systemd soit retiré ?
Le truc c'est que soit ils ont décidé de mettre systemd quoi qu'il arrive, mais qu'ils tiennent absolument à nous faire la surprise (ce que tu as l'air de penser), soit ils ne sont pas sur de mettre 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,
Et dans la plupart des cas j'en ai rien à faire. Mais dans le cas présent si il faut porter tous les scripts d'init custom j'aimerai pouvoir commencer en avance. Maintenant je ne suis pas categoriste, si le support n'a pas le droit de répondre, je prend la réponse de n'importe qui d'officiel à la place. Seulement cette réponse (à l'heure actuelle) je ne l'ai pas.
Le fait que Solaris soit passé à smf est la preuve qu'on peut survivre à un changement de système d'init.
J'ai aucun problème avec un changement d'init. J'ai un problème majeur avec systemd. SMF est une réussite et si on pouvait avoir un truc pareil sous Linux je ferais des bonds de joie. Les points forts de SMF sont :
- Tout un système basé quasi exclusivement sur les templates : tous les services sont des templates, et on peut facilement créer et détruire des instances à la volée en changeant les paramètres de configuration ou en dupliquant une instance existante.
- Des dépendances ultra-réduites. Pas besoin de ramener une pléthore d'outils pour que ca marche.
- Un grand respect de l'existant : les scripts de rc.d/* continuent d'être executés. inittab est toujours parsé etc.
- Un système turing complet avec des vrais outils pour manipuler l'environnement d’exécution des services aussi bien avant le démarrage que pendant l’exécution.
Et pléthore d'autres trucs qui font cruellement défaut à systemd.
Si on se logue trop tôt et qu'on utilise NIS. Et comme tu dit, c'est corrigé dans une nouvelle version systemd.
Le problème n'est pas là. Le problème est comment une interaction de ce type peut-elle tromper l'init et le faire se comporter de façon nocive pour le système ? Un getty crashe (ca peut arriver), ben on le relance.
Ce qui est le comportement standard de sysvinit et de tout les autres. Et d'après le bug, c'est plymouthd qui bloque.
Une fois de plus le problème n'est pas la. Que /var ne se démonte pas parcequ'il est locké OK, mais pourquoi au reboot systemd devient-il incapable de monter /var ? Je n'ai jamais eu d'erreur de type 'ah non, il y a un fichier de lock alors j'interdis le montage' sur sysinit ou sur bsdinit. Comment un fichier à la con peut-il empêcher /var de monter ?
Que le fichier vienne de plymouth on s'en fout.
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.
Au hasard parce que justement comme le système n'est pas prédictif, j'aimerais bien pouvoir lancer B avant A pour voir ce qui se passe. Par exemple si j'ai un bug qui se produit une fois sur 5 ou 6 et que je pense que c'est la fois ou le service TUTU se lance avant le service TOTO qui est normalement toujours premier à s'executer. Là pour faire ce genre de tests il faut que je fasse dépendre artificiellement TOTO de TUTU (et bien entendu que je remette les trucs dans le bon ordre si c'est pas ça). Si j'ai trois ou quatre hypothèses je vais me marrer.
C'est pas un souci de systemd, c'est un souci de nfs sur Suse, et Fedora 18 propose les unités pour nfs.
Non. C'est bien un manque de systemd (pas un problème à proprement parlé, mais un comportement inattendu) que l'on peut contourner. Les sockets virtuels foutent la grouille entre les différents process de NFS et comme automount part très vite on est obligé de broder un peu pour que ypbind et autofs soient actifs et en forme pour de vrai au moment ou automount vient les chercher.
Comme dit dans le bug report, tu t'attends à quoi ?
Tu es en train d'insinuer que c'est un comportement normal de tuer l'init quand un disque ram est plein ? Comme dit le bug report une ligne plus bas, je m'attends plutôt à ce que l'on arrive sur un refus genre "disque plein" avec des retry et des purges (enfin comme sur n'importe quel autre fs quoi).
Donc je compte 2 bugs déjà corrigés, 2 bug à corriger ailleurs ( nfs, plymouthd ), et 1 "why did you expect".
Donc bien 5 bugs, des trucs qui peuvent se produire et qui explosent l'init.
Et les corrections ne sont pas coté systemd (genre ah oui, dans ce cas dégénéré là ca empêche l'init - c'est embêtant quand même) mais coté des outils. Genre ok le logiciel de haut niveau TOTO a planté l'init, mais c'est de sa faute il a pas fait les appels comme il faut et c'est corrigé dans la version 4.2 du logiciel TOTO.)
Le problème est que le logiciel de haut niveau TOTO ne devrait pas pouvoir planter l'init. Pas du tout. Bordel c'est l'init ! Ca doit être bétonné.
Comme avec chaque version majeur. Est ce qu'ils ont eu des tonnes de boulot avec upstart sur les RHEL 6 ?
Grosso modo upstart ca a foutu la grouille dans les configs TTY à la con et les runlevels custom, mais c'était pas bien méchant au final. Ne serait-ce que parce qu'on avait toujours les scripts et l'environnement.
Sinon, quand tu payes la souscription RHEL ou SLES, c'est aussi pour que le distributeur fasse les tests
Le distributeur il t'aide en cas de pépin et il peut débugguer des trucs pas évident. Mais il n'a pas un clone de ton install chez lui. Donc pour faire les tests…
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.
Les trucs qui dépendent du mot de passe sont nécessairement bloqués (en fait c'est même le but d'un mot de passe) - Les trucs qui ne dépendent pas du mot de passe continuent. Quand il y a plusieurs mots de passe, pour s'y retrouver on affiche un texte explicatif (Genre veuillez rentrer le mot de passe pour le certificat truc de l'instance apache www.example.com )
Je pense au passage que c'était pas possible non plus avec upstart qui dans mon souvenir lance les trucs en parallèle.
Si si, ça marche très bien. Parce que upstart execute des scripts et sait mettre les demande d'interaction utilisateur à la queue leu leu.
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é
Un truc super compliqué : une variable d'environnement dont le contenu n'est pas fixe.
Un autre truc super compliqué : le résultat de l’exécution d'un autre service.
Heureusement ça arrive rarement les service qui donne des résultats ou les variables d'environnement qui changent.
Formidable ça. Parce que upstart ou l'init classique sysinit, c'était normalisé ?
Non mais c'était turing complet. Donc on pouvait TOUJOURS trouver une solution ou un contournement.
Bie sur, tu va trouver sans doute des cas de scripts hors lsb qui ne marche pas, et dire "bah ça marche pas".
Il y a des scripts d'init full LSB qui ne marchent pas. Pour les partitions chiffrées notamment.