|
|
Le 05-06-2020, JKB <jkb> a écrit :
> Le 05 Jun 2020 10:21:44 GMT, > Stéphane CARPENTIER <sc> écrivait : >> Je comprends aussi pourquoi les machines sous-dimensionnées de JKB ont >> du mal à démarrer. > Dans l'embarqué, tu ne te trimballes pas 4 Go de mémoire pour te > faire plaisir. Je ne vois pas en quoi avoir seulement 512 Mo de > mémoire est sous-dimensionné pour l'immense majorité des cas. OK, je croyais que c'étaient des vieux serveurs. Mais l'embarqué, si c'est pas du serveur, c'est pas du poste de travail non plus. OK, je ne faisais que la distinction serveur/desktop et effectivement, l'embarqué est clairement une autre catégorie plus proche du serveur que du poste de travail. > Par ailleurs, certains problèmes de systemd seraient acceptables si, > par exemple, on pouvait simplement lui demander de ne pas essayer de > tout lancer en parallèle. Ça me semble dur car ça me semble prévu par design. Et effectivement, ce que j'ai vu de systemd n'est pas fait pour l'embarqué. Tu ne peux pas dire qu'il suffit de lire le socket en attendant que le périphérique soit prêt on ne sait pas trop quand. Enfin pas sur de l'embarqué, sur du poste de travail, je ne vois pas le problème. Ce n'est pas parce que systemd est vraiment orienté poste de travail qu'il doit être considéré comme néfaste sur les postes de travail. C'est comme le gestionnaire de fenêtre, c'est super sur un poste de travail, c'est plus discutable sur un serveur, sur de l'embarqué, j'ai encore plus de mal à voir. Pourquoi le système d'initialisation devrait être le seul composant du système d'exploitation qui devrait être identique partout ? > Sauf erreur de je n'ai pas trouvé dans la doc un drapeau de > configuration permettant de dire à systemd "merci de ne pas forker > comme un goret et d'être gentil en lançant tout séquentiellement". Je ne me suis pas plongé dedans, mais d'après ce que j'en comprends, c'est by design et tu ne devrais rien trouver. Il faudrait que j'analyse plus ce que ça fait quand j'ai dit à systemd qu'un service devait être démarré après un autre. Parce que par disgn, puisqu'à la place de lier directement deux services, tu fais un socket (je ne sais plus je crois que ce n'est pas le terme mais le principe). Du coup, tu n'as plus à t'énerver à savoir dans quel ordre chaque composant doit se lancer, le noyau met en cache en attendant que l'autre soit prêt. Du coup, tu lances tout en parallèle et il n'y en a pas un qui ralenti l'autre. Sauf que si tu es limité en mémoire avec un périphérique lent à démarrer, la mise en cache du noyau peut saturer ta mémoire. L'avantage, c'est que sur un poste de travail, tu peux venir avec ton matériel et brancher et débrancher tes trucs à l'envie (je me souviens de Windows NT où lorsque tu débranchais ta souris il fallait rebooter). Mais c'est un avantage pour un poste de travail, sur un serveur ou un matériel embarqué, le plug-and-play ont moins leur place. >> Mais d'un autre côté, devoir attendre deux minutes >> qu'un périphérique non vital soit reconnu sur ma machine pour pourvoir >> l'utiliser parce que sinon, les serveurs qui ont 40 ans ne démarrent pas >> me gêne. > Ce qui me dérange plus, c'est l'attente infinie sur certains > périphériques non critiques. Ça, si je comprends ce que tu veux dire, c'est pour permettre le plug-and-play. > Ou le simple fait que l'ordonnanceur ne soit pas fiable : ce qui > fonctionnait avec telle version de systemd est fichu de ne plus se > lancer dans le même ordre avec la version suivante. D'après ce que je comprends de la conception, c'est que le but est justement de ne pas avoir s'énerver avec l'ordonnanceur puisque tout est lancé en même temps et si l'un est pas prêt, le noyau catch les messages en attendant que l'autre soit prêt. Du coup, je ne suis pas trop surpris que l'ordonnanceur ne soit pas fiable. Pour moi, ça va surtout poser des problèmes sur l'embarqué ou sur des serveurs, pas sur des postes de travail. > Alors il est vrai que c'est sur des trucs comme des > disques iSCSI ou des choses bizarres qu'on ne retrouvera pas chez > madame Michu (enfin, normalement), mais lorsque tu redémarres une > machine, tu aimes bien que ça se comporte de manière prévisible > d'une version à l'autre. Avec systemd, ce n'est pas le cas. Ça > ressemble vraiment au démarrage de type Windows avec en plus un > petit air d'advienne que pourra. De ce que je comprends, oui, c'est le principe. Pas de lancer à la Windows, mais de tout lancer en même temps et quand tout sera lancé tout marchera. Si tu remarques qu'il y a un truc qui s'est bannané, tu corriges le truc en question et tout ce qui en dépendait fonctionne (je te parles de la théorie, là, hein, du principe, dans la vraie vie, ça dépend : ça dépasse). Sur de l'embarqué, tu peux pas te le permettre. Une fois que ton satellite est dans l'espace tu ne peux pas remarquer que tu as un truc dans la main que tu as oublié de brancher. Mais sur un poste de travail, ça a du sens. [..] > manière. J'ai pensé naïvement qu'il utilisait toujours en priorité > ses modules. Raté, ce n'est pas toujorus vrai (je n'ai pas cherché à > savoir si c'était un bug ou une fonctionnalité). Là, oui, D'après ce que j'ai compris, le but est de permettre de basculer en douceur de SysV à systemd. Le bon admin sys ou le bon gestionnaire de distribution devrait donc dégager tout SysV et ne garder que systemd. Pendant la phase de transition ou parce que quelqu'un a décidé de garder des scripts SysV jusqu'au bout, oui, ça peut poser des problèmes. > C'est un merdier sans nom d'autant plus que je suis tombé sur une > bizarrerie d'un paquet debian qui modifie /lib/systemd/system et... > qui est réécrasé à la prochaine mise à jour de systemd. Mais là, si debian fait n'importe quoi avec sa gestion des configurations, ce n'est pas un problème systemd. Il aurait pu faire tomber n'importe quelle partie de ton système. > Pourquoi est-ce que les devs de systemd n'ont pas tout mis au même endroit > en retirant /etc/init.d de l'équation ? Ça je ne sais pas, je ne me suis pas plongé dedans, mais quand j'ai installé mon système, j'ai mangé pour savoir où étaient installés mes trucs. Arriver sur systemd, c'est assez ardu, oui. > Mais le résultat est qu'on a un truc qui explose en vol plus souvent > qu'à son tour. Chez moi c'est stable mais c'est un poste de travail. > Il y a aussi un truc étrange depuis quelques semaines. Lorsque mon > poste de travail (diskless avec swap en iSCSI) se met à swapper un > peu trop, systemd me ferme ma session graphique. C'est très gentil > de sa part et très pratique. Je suppose qu'il y a maintenant dans le > bouzin un genre de watchdog. Le seul truc que j'ai vu sur les processus utilisateurs, c'est qu'il les ferme sur des utilisateurs délogués. Certains considèrent que c'est un bug, d'autre une fonctionnalité. Mais les processus utilisateurs logués, je ne sais pas. > Dernière chose, et non des moindres. Les mises à jour de systemd > sont problématiques parce une nouvelle version de la chose prend > place sur une machine utilisant déjà systemd comme init (pid 1). Et > là, le redémarrage peut être problématique avec des processus > d'extinction qui ne finissent JAMAIS (attente infinie sur... rien > parce que la version du binaire a changé !). Je ne sais pas si j'ai eu des maj de systemd (je suppose quand même), mais je n'ai jamais eu de problème. Lors des maj, je regarde juste s'il y a eu des versions du noyau pour le recopier sur le répertoire de boot. > En fait, avec systemd, on est arrivé à un état problématique. Plus > exactement, il est désespérant de voir que ce que les développeurs > de Linux il y a 20 ans reprochaient à Windows se retrouve tel quel > avec les mêmes inconvénients dans Linux. Tu peux voir systemd comme une étape aussi. Là, on a un truc énorme qui fait plus que de l'init. Mais d'abord, il permet de s'affranchir du shell. Ensuite, il oblige à une certaine homogénéisation : pour s'interfacer il faut que les autres suivent un certain formalisme. Ce qui fait peur à certains. Mais à partir du moment où c'est un format ouvert, c'est pas forcément choquant d'avoir une norme. Ensuite, une fois que tout ce qui est initialisé au démarrage par systemd est uniforme, il sera possible de remplacer systemd par un ou plusieurs autres systèmes mieux conçus qui ne nécessiteront que les mêmes interfaces. > Après aussi, remarque bien. Peut-être, mais ça peut pas être pire qu'avant. Et j'ai moins de contrainte après que pendant. Parce que pendant, il fallait aussi que je découvre l'uefi par exemple. Entre autre. > Systemd est piégeux, son développement n'a visiblement pas été plus > ou pas été mieux pensé que celui de PL/1. Nouveau besoin, nouveau > patch et, à la fin, on a une usine à gaz avec des fuites qui marche > dans 95% des cas. Tant pis pour toi si tu es dans les 5% restants. Je ne dis pas que c'est parfait systemd. Mais pour SysV c'est pas tout rose non plus. Et pour les autres, à part dire que puisque c'est pas systemd c'est forcément mieux, j'ai jamais vu d'explication sur leurs points forts. Mais pour moi, systemd, c'est un peu comme Android. Il y a des défauts, mais ça fait son travail et je n'ai pas vu d'alternative valable. |
|
|
|
Le 05 Jun 2020 14:35:06 GMT,
Stéphane CARPENTIER <sc> écrivait : [..] > poste de travail, je ne vois pas le problème. > Ce n'est pas parce que systemd est vraiment orienté poste de travail > qu'il doit être considéré comme néfaste sur les postes de travail. Mais je me contrefous royalement du fait qu'il peut ne pas être néfaste sur un poste de travail. Si systemd était _juste_ un système de démarrage, je n'aurais a priori rien contre s'il était bien ficelé. Le problème est qu'il n'est pas que cela et que de plus en plus de soft s'appuient sur systemd pour tourner. Et là, c'est assez catastrophique parce que, soit tu es contraint de te taper l'insertion dans d'autres systèmes d'init, soit tu es obligé de faire avec systemd même si tu n'en veux pas. > C'est > comme le gestionnaire de fenêtre, c'est super sur un poste de travail, > c'est plus discutable sur un serveur, sur de l'embarqué, j'ai encore > plus de mal à voir. Pourquoi le système d'initialisation devrait être le > seul composant du système d'exploitation qui devrait être identique > partout ? Parce qu'aujourd'hui, tu n'as pas vraiment le choix sauf à taper dans de la distribution Linux customisée à mort. Si tu veux tourner sur un arm, tu as bien plus intérêt à prendre une debian armhf qu'une distribution pour l'embarqué (sauf cas très spéciaux avec des ressources très limitées ou des composants scabreux). Pourquoi ? Parce que ces distributions ont beaucoup plus d'utilisateurs et les bugs sont remontés bien plus vite et corrigés. Dans les distributions pour l'embarqué, tu peux avoir des bugs qui traînent des années (j'ai des souvenirs cuisants avec les Mips et les iMX-6). > Je ne me suis pas plongé dedans, mais d'après ce que j'en comprends, > c'est by design et tu ne devrais rien trouver. Il faudrait que j'analyse > plus ce que ça fait quand j'ai dit à systemd qu'un service devait être > démarré après un autre. > Parce que par disgn, puisqu'à la place de lier directement deux > services, tu fais un socket (je ne sais plus je crois que ce n'est pas > le terme mais le principe). Du coup, tu n'as plus à t'énerver à savoir > dans quel ordre chaque composant doit se lancer, le noyau met en cache > en attendant que l'autre soit prêt. Du coup, tu lances tout en parallèle > et il n'y en a pas un qui ralenti l'autre. Ça, c'est la théorie. La théorie, c'est toujours beau dans un monde aux ressources illimitées. > Sauf que si tu es limité en mémoire avec un périphérique lent à > démarrer, la mise en cache du noyau peut saturer ta mémoire. Voilà. > L'avantage, c'est que sur un poste de travail, tu peux venir avec ton > matériel et brancher et débrancher tes trucs à l'envie (je me souviens > de Windows NT où lorsque tu débranchais ta souris il fallait rebooter). > Mais c'est un avantage pour un poste de travail, sur un serveur ou un > matériel embarqué, le plug-and-play ont moins leur place. On sait faire cela sans systemd, faut pas exagérer ! > Ça, si je comprends ce que tu veux dire, c'est pour permettre le > plug-and-play. Non. Il y a des cas très drôles d'ordre de montage de disques qui aboutissaient une fois sur deux à un blocage au boot (un vrai, seul moyen de s'en tirer, le bouton reset !). Rien à voir avec le plug'n-play. J'ai aussi un cas récent (un peu particulier je l'avoue) d'une machine qui fait tourner une petite base de données MySQL sur un disque NFSv3/TCP. J'ai beau indiquer à systemd que Mariadb doit être lancé après que les disques sont montés, systemd n'en a rien à faire une fois sur deux et le service échoue. Il y a des cas marants aussi sur les interfaces réseau avec des choses comme les VPN. Il faut d'abord que les interfaces physiques soient montées, puis les VPN et enfin les services dépendant de ces VPN. Problème : si tu configures dans Apache des interfaces explicitement, le truc se tire une balle dans le pied une fois sur deux. Et la solution que tu trouves après avoir étudié le fonctionnement du machin est valable pour la version n et pas pour la n+1 la plupart du temps. Sans compter que systemd vient aussi avec certaines versions du noyau. Et je te prie de croire que je fais la différence entre After, Wants et les autres mots-clefs de configuration. Il y a même des cas où des services ne démarrent pas sans aucune explication valable (je pense à Zoneminder récemment) : tout est bon, mais systemd échoue à le faire démarrer (alors que la même commande en ligne de commande fonctionne parfaitement). >> Ou le simple fait que l'ordonnanceur ne soit pas fiable : ce qui >> fonctionnait avec telle version de systemd est fichu de ne plus se >> lancer dans le même ordre avec la version suivante. > D'après ce que je comprends de la conception, c'est que le but est > justement de ne pas avoir s'énerver avec l'ordonnanceur puisque tout est > lancé en même temps et si l'un est pas prêt, le noyau catch les messages > en attendant que l'autre soit prêt. Et c'est justement le problème. Une explosion de consommation de ressources, de PID... > Du coup, je ne suis pas trop surpris que l'ordonnanceur ne soit pas > fiable. Pour moi, ça va surtout poser des problèmes sur l'embarqué ou > sur des serveurs, pas sur des postes de travail. Rien à voir. Les BSD par exemple utilisent un système avec des balises REQUIRE et PROVIDE. C'est fiable et l'ordonnanceur se débrouille sans forker dans tous les sens. Je rajoute que j'ai deux serveurs dans des configurations à peu près identiques, l'un sous Linux (debian/testing), l'autre sous NetBSD 9.0. Le BSD fait le même boulot (même plus) et démarre trois fois plus vite que le Linux. Et je n'ai pas à croiser les doigts pour que tout démarre correctement. > De ce que je comprends, oui, c'est le principe. Pas de lancer à la > Windows, mais de tout lancer en même temps et quand tout sera lancé tout > marchera. Si tu remarques qu'il y a un truc qui s'est bannané, tu > corriges le truc en question et tout ce qui en dépendait fonctionne (je > te parles de la théorie, là, hein, du principe, dans la vraie vie, ça > dépend : ça dépasse). Sur de l'embarqué, tu peux pas te le permettre. > Une fois que ton satellite est dans l'espace tu ne peux pas remarquer > que tu as un truc dans la main que tu as oublié de brancher. Mais sur un > poste de travail, ça a du sens. Pas plus en fait. Le seul intérêt de la chose est de présenter une durée de boot la plus petite possible. Et j'avoue que ce genre de compétition me dépasse. > Là, oui, D'après ce que j'ai compris, le but est de permettre de > basculer en douceur de SysV à systemd. Le bon admin sys ou le bon > gestionnaire de distribution devrait donc dégager tout SysV et ne garder > que systemd. Pendant la phase de transition ou parce que quelqu'un a > décidé de garder des scripts SysV jusqu'au bout, oui, ça peut poser des > problèmes. Le problème n'est pas là. Lorsque je veux utiliser un script /etc/init.d, systemd n'a pas à intérférer là-dedans pour utiliser un bout de /etc/systemd ou /lib/systemd (sans le dire, sinon, ce n'est pas drôle). Point barre. Il ne sait pas mieux que moi ce que je veux faire. >> C'est un merdier sans nom d'autant plus que je suis tombé sur une >> bizarrerie d'un paquet debian qui modifie /lib/systemd/system et... >> qui est réécrasé à la prochaine mise à jour de systemd. > Mais là, si debian fait n'importe quoi avec sa gestion des > configurations, ce n'est pas un problème systemd. Il aurait pu faire > tomber n'importe quelle partie de ton système. Certes. C'était juste pour indiquer l'incohérence de la chose. [..] >> Je ne sais pas si j'ai eu des maj de systemd (je suppose quand même), > mais je n'ai jamais eu de problème. Lors des maj, je regarde juste s'il > y a eu des versions du noyau pour le recopier sur le répertoire de boot. >> Tu peux voir systemd comme une étape aussi. Là, on a un truc énorme qui > fait plus que de l'init. Mais d'abord, il permet de s'affranchir du > shell. En quoi est-ce une bonne chose ? > Ensuite, il oblige à une certaine homogénéisation : pour > s'interfacer il faut que les autres suivent un certain formalisme. Ce > qui fait peur à certains. Effectivement, si on écrit des scripts rcorder ou SysV à l'arrache, ça ne fonctionnera pas bien. Dans tous les systèmes, il y a un formalisme à respecter sous peine de se prendre un coup de pied dans les fesses. > Mais à partir du moment où c'est un format > ouvert, c'est pas forcément choquant d'avoir une norme. Ensuite, une > fois que tout ce qui est initialisé au démarrage par systemd est > uniforme, il sera possible de remplacer systemd par un ou plusieurs > autres systèmes mieux conçus qui ne nécessiteront que les mêmes > interfaces. Pourquoi ne pas faire juste une seule fois le boulot ? > Peut-être, mais ça peut pas être pire qu'avant. Et j'ai moins de > contrainte après que pendant. Parce que pendant, il fallait aussi que je > découvre l'uefi par exemple. Entre autre. Je ne vois franchement pas le rapport. > Je ne dis pas que c'est parfait systemd. Mais pour SysV c'est pas tout > rose non plus. Et pour les autres, à part dire que puisque c'est pas > systemd c'est forcément mieux, j'ai jamais vu d'explication sur leurs > points forts. Le meilleur système serait un mix entre SysV et rcorder. Différents _vrais_ runlevels (pas les trucs dégénérés de systemd) et à l'intérieur de ces runlevels, des bouts de rcorder pour ordonner proprement le tout. C'est un peu ce qu'on trouvait dans la Redhat 5.0 (celle de la fin des années 1990), ça ne nous rajeunit pas. > Mais pour moi, systemd, c'est un peu comme Android. Il y a des défauts, > mais ça fait son travail et je n'ai pas vu d'alternative valable. Ah. JKB |
|
|
Stéphane CARPENTIER , dans le message
<slrnrdkm0q.7b7l.sc>, a écrit : > Ça me semble dur car ça me semble prévu par design. Oui. Pour résumer la moitié de ton échange : quand on essaie de faire avec systemd la même merde qu'on faisait avec SysV init, ben ça môrche pô. > Le seul truc que j'ai vu sur les processus utilisateurs, c'est qu'il les > ferme sur des utilisateurs délogués. Certains considèrent que c'est un > bug, d'autre une fonctionnalité. C'est optionnel et configurable, donc ceux qui prétendent que c'est un bug sont de mauvaise foi. |
|
|
Le 05-06-2020, JKB <jkb> a écrit :
> Le 05 Jun 2020 14:35:06 GMT, > Stéphane CARPENTIER <sc> écrivait : >> Ce n'est pas parce que systemd est vraiment orienté poste de travail >> qu'il doit être considéré comme néfaste sur les postes de travail. > Mais je me contrefous royalement du fait qu'il peut ne pas être > néfaste sur un poste de travail. Pas moi, parce que c'est ce que j'utilise. La guerre contre systemd n'est pas une guerre contre systemd sur le serveur mais global. Les sites internet critiquant systemd disent que personne ne doit l'utiliser parce que c'est le mal absolu. Mais que ce soit le mal absolu pour les serveurs ou pour l'embarqué n'est pas mon problème. Moi, c'est sur un poste de travail que je l'utilise. > Si systemd était _juste_ un système > de démarrage, je n'aurais a priori rien contre s'il était bien > ficelé. Je ne sais pas à quel point il est mal ficelé. Moi ce que je sais, c'est que ça marche bien chez moi. Ce que je vois, c'est que, ce après quoi tu râles, j'ai l'impression que ça se résume en trois trucs : - le manque de fiabilité des montés de versions. Quand tu me parles des fichiers de configuration mal gérés par debian, je me demande à quel point le sujet ne vient pas plus de debian que de systemd. Parce que si les options des fichiers de conf que tu ne modifies pas sont changées à chaque montée de version, ceci peut expliquer cela. - le mélange entre les confs de SysV et de systemd. Pareil, quand c'est sorti, systemd devait probablement bien avoir besoin de certaines parties de SysV, mais depuis j'ai tendance à croire que systemd n'a absolument plus besoin de SysV. Donc, si les deux se marchent sur les pieds, c'est peut-être parce que debian essaye de les faire cohabiter tant bien que mal. Pareil, si c'est le cas, c'est pas de la faute de systemd si debian n'arrive pas à les faire cohabiter, surtout si c'est pas utile. - tu as quand mêmes des besoins particulièrement spécifiques. Si debian a du mal à gérer la cohabitation entre systemd et SysV, je ne suis pas surpris qu'ils n'aient pas testés tes cas particulier. Pareil, c'est pas non plus de la faute de systemd si c'est debian qui n'a pas testé tes cas particuliers. > Le problème est qu'il n'est pas que cela et que > de plus en plus de soft s'appuient sur systemd pour tourner. Et là, > c'est assez catastrophique parce que, soit tu es contraint de te > taper l'insertion dans d'autres systèmes d'init, soit tu es obligé > de faire avec systemd même si tu n'en veux pas. Je ne suis pas trop sûr de comprendre. Les cas que tu m'as montrés sont des exemples super particuliers. Tu veux dire que tu as généralisé ces cas particuliers ? > Si tu veux tourner sur un arm, tu as bien plus intérêt à prendre une > debian armhf qu'une distribution pour l'embarqué (sauf cas très > spéciaux avec des ressources très limitées ou des composants > scabreux). Ça, c'est peut-être une partie du problème. Avant, l'embarqué, ils développaient tout parce que les ressources étaient limités. Maintenant, on met un Linux dedans parce que les ressources ont augmentés et c'est plus facile. Après, que les distributions grand public ne soient pas prévues pour faire de l'embarqué, oui, je veux bien te croire. > Pourquoi ? Parce que ces distributions ont beaucoup plus > d'utilisateurs et les bugs sont remontés bien plus vite et corrigés. > Dans les distributions pour l'embarqué, tu peux avoir des bugs qui > traînent des années (j'ai des souvenirs cuisants avec les Mips et > les iMX-6). Oui, quand le satellite est dans l'espace, c'est plus dur de faire une mise à jour. Sur un avion ou sur un train, il suffit d'attendre qu'il arrive au contrôle. Mais normalement, l'avantage d'un truc au petits oignons pour de l'embarqué, c'est que tas moins de composants et moins de bugs. J'en connais un qui a fait des tests sur des radars pour aéroport. Les tests ça rigole pas, c'est pas des tests de Windows. Les tests sont faits en double, dans deux langages de programmation. Et il y a un logiciel qui fait des tests automatique puis un autre logiciel pour tester le logiciel qui lance les tests. Ça m'étonnerait que dans son cas il y ait eu un bug critique non corrigé pendant des années. J'ai vu des mecs qui programment en ADA pour de l'embarqué et c'est pareil, il était pas inquiet pour les bugs. La difficulté c'était la compilation. >> L'avantage, c'est que sur un poste de travail, tu peux venir avec ton >> matériel et brancher et débrancher tes trucs à l'envie (je me souviens >> de Windows NT où lorsque tu débranchais ta souris il fallait rebooter). >> Mais c'est un avantage pour un poste de travail, sur un serveur ou un >> matériel embarqué, le plug-and-play ont moins leur place. > On sait faire cela sans systemd, faut pas exagérer ! J'ai pas dit que c'est sytemd qui l'a inventé. À partir du moment où rien n'est centralisé pour le gérer, chaque matériel doit être géré à l'unité (éventuellement en groupe par exemple CUPS pour les imprimantes). À partir du moment où c'est pris en charge en central, ça simplifie la vie de celui qui fabrique un matériel (il n'a qu'à définir comment il doit être initialisé) et de celui qui l'utilise. >> Ça, si je comprends ce que tu veux dire, c'est pour permettre le >> plug-and-play. > Non. Il y a des cas très drôles d'ordre de montage de disques qui > aboutissaient une fois sur deux à un blocage au boot (un vrai, seul > moyen de s'en tirer, le bouton reset !). Rien à voir avec le > plug'n-play. OK, ça c'est bizarre. Que systemd ne gère pas bien l'ordre de démarrage, je le veux bien, que systemd soit responsable du blocage, je suis moins sûr. >> D'après ce que je comprends de la conception, c'est que le but est >> justement de ne pas avoir s'énerver avec l'ordonnanceur puisque tout >> est lancé en même temps et si l'un est pas prêt, le noyau catch les >> messages en attendant que l'autre soit prêt. > Et c'est justement le problème. Problème pour serveur et embarqué, je veux bien. Pour poste de travail, je n'ai rien vu. > Une explosion de consommation de ressources, de PID... Pour les ressources, je ne sais pas. Une fois que tout est démarré, le noyau libère son cache et les ressources sont libérées. Pour le nombre de PID, faut se mettre d'accord. Soit c'est la philosophie Unix de la séparaion des tâches et ça donne une augmentation des PID. Soit on a un truc monolithique qui fait tout avec un seul PID. Une augmentation du nombre de PID est plutôt une bonne nouvelle pour moi, ça veut dire que c'est moins monolithique que ce qui est annoncé. >> Tu peux voir systemd comme une étape aussi. Là, on a un truc énorme qui >> fait plus que de l'init. Mais d'abord, il permet de s'affranchir du >> shell. > En quoi est-ce une bonne chose ? En gros, je ne sais pas si j'ai vu un shell sh une fois dans ma vie. C'est possible, mais c'est très vieux et je n'y avais pas fait attention. Depuis de nombreuses années, le /bin/sh, c'est un lien vers autre chose. J'ai vu dash, bash, il doit y en avoir d'autres. Or, c'est quasiment tout le temps, défini comme un script sh. Ce qui fait qu'avec un développeur propre et consciencieux, il reste dans les limites du sh. Mais quelqu'un de moins rigoureux va rajouter des basheries ou des dasheries (je ne sais pas s'il y a autant de spécificité que pour bash) ou des ce que tu veux dans son script. Et quand il va rajouter des spécificité sans s'en rendre compte, il va les distribuer. Et tant que tout le monde a le même shell par défaut, ça marche. Mais si pour une raison quelconque, tu changes il y a des effets de bord que tu ne vas pas comprendre. Si des mainteneurs de distribution veulent changer leur shell par défaut, il y a plein de trucs à prendre en compte qui n'ont pas lieu d'être. >> Mais à partir du moment où c'est un format ouvert, c'est pas >> forcément choquant d'avoir une norme. Ensuite, une fois que tout ce >> qui est initialisé au démarrage par systemd est uniforme, il sera >> possible de remplacer systemd par un ou plusieurs autres systèmes >> mieux conçus qui ne nécessiteront que les mêmes interfaces. > Pourquoi ne pas faire juste une seule fois le boulot ? D'abord, ce ne sont pas forcément les mêmes qui vont faire la deuxième étape (s'il y en a une, je ne suis pas visionnaire c'est une possibilité). Les premiers n'ont pas forcément prévu de basculer. Ensuite, Ça peut être plus facile de procéder par étape. Enfin, il y a toujours une partie retour d'expérience. C'est facile une fois que le boulot est fini de voir comment il aurait fallu faire. C'est rarement tout bon ou tout mauvais. Mais c'est quand on a fini qu'on peut voir les amélioration : en apprenant de ses erreurs. |
|
|
Le 05-06-2020, Nicolas George <nicolas$george> a écrit :
> Stéphane CARPENTIER , dans le message ><slrnrdkm0q.7b7l.sc>, a écrit : >> Le seul truc que j'ai vu sur les processus utilisateurs, c'est qu'il les >> ferme sur des utilisateurs délogués. Certains considèrent que c'est un >> bug, d'autre une fonctionnalité. > C'est optionnel et configurable, donc ceux qui prétendent que c'est un bug > sont de mauvaise foi. Possible, je ne sais pas et je n'ai pas cherché à savoir. Chez moi, quand je me déconnecte de mon poste de travail, c'est pour l'éteindre. Donc, les processus sont destinés à s'arrêter quoiqu'il arrive. Les nohup qui durent des heures, ça fait longtemps que je n'ai pas cherché à en lancer. Par contre, j'ai vu d'autres process, gnome ou KDE je ne sais plus, qui continuaient à tourner quand je me déconnectais et qui bouffaient des ressources quand je me connectais avec un autre compte. Je devais les tuer manuellement et ça m'aurait plu que ce soit fait automatiquement. C'est pour ça que comme je ne connais pas je ne sais pas s'il y a plus d'inconvénients que d'avantages ou pas. Si c'est très compliqué à configurer (j'en sais rien) ça peut ne pas être agréable. |
|
|
Le Fri, 05 Jun 2020 10:21:44 +0000, Stéphane CARPENTIER a écrit :
> Le 04-06-2020, Yliur <yliur> a écrit : >> Le message en question : >> [..] > Ah, ben non. Moi qui voulait détester systemd, tu vas finir par faire de > moi un défenseur. Ah bah désolé... :) Personnellement quand arch est passé à systemd j'ai appris quelques commandes, arrêté d'utiliser "/etc/rc.d/service restart" au profit de "systemctl restart service" et ça s'est un peu arrêté là... J'ai suivi quelques discussions sur systemd mais pour ce que j'en fais ça ne change pas grand chose à ma vie. > Le problème de cette page en particulier, comme de ce wiki en général, > c'est que c'est plus une liste de recettes qu'une doc. Si tu connais > systemd, c'est très bien. Si tu découvres systemd en arrivant sur > archlinux, tu fais des devinettes en espérant que ça marche. Ils > t'expliquent comment faire, mais pas pourquoi. Et se plonger dans la doc > de systemd au moment de l'installation d'un OS est quand même très > contraignant. Mais au moment de l'installation d'arch, tu suis la page d'installation et pas celle de systemd, non ? Qu'est-ce que tu as besoin de savoir sur systemd quand tu fais une installation arch ? Pour moi quand tu fais ton installation archlinux sans savoir exactement où tu vas ni connaître les outils, tu suis la procédure sans trop en dévier et ça te permet de savoir un peu que telle ou telle partie se configure à tel ou tel endroit (et aussi d'avoir une machine fonctionnelle). Ensuite tu peux explorer les détails et toucher des choses, et là la page de wiki de systemd est intéressante. Plus tard encore si tu veux creuser le fonctionnement de systemd, la page de wiki liste des docs (à la fin). |
|
|
Le Fri, 05 Jun 2020 15:39:42 +0000, JKB a écrit :
> Le problème n'est pas là. Lorsque je veux utiliser un script > /etc/init.d, > systemd n'a pas à intérférer là-dedans pour utiliser un bout de > /etc/systemd ou /lib/systemd (sans le dire, sinon, ce n'est pas drôle). > Point barre. Il ne sait pas mieux que moi ce que je veux faire. De ce que je lis dans la doc systemd d'archlinux, il existe plusieurs endroits pour différencier ce qui est installé par les paquetages et ce que l'admin système veut faire lui (et qui a la priorité). Et pour séparer les services qui peuvent être sous contrôle des utilisateurs des autres. Ça a l'air assez bien établi. Après si ta distribution mélange tout, ça peut être une période de transition ou simplement que c'est mal fichu, je ne sais pas. Mais systemd ne semble pas dire qu'il veut décider à ta place ce que tu veux faire, il te laisse un endroit où placer les modifications que tu veux sans avoir à écraser ce qui est écrit dans les paquets. |
|
|
Le 05 Jun 2020 22:05:39 GMT,
Stéphane CARPENTIER <sc> écrivait : > Le 05-06-2020, JKB <jkb> a écrit : > Pas moi, parce que c'est ce que j'utilise. La guerre contre systemd > n'est pas une guerre contre systemd sur le serveur mais global. Les > sites internet critiquant systemd disent que personne ne doit l'utiliser > parce que c'est le mal absolu. Mais que ce soit le mal absolu pour les > serveurs ou pour l'embarqué n'est pas mon problème. Moi, c'est sur un > poste de travail que je l'utilise. Remarque bien, il n'y a aucune raison que les problèmes rencontrés ailleurs que sur un poste de travail ne finissent pas par arriver sur un poste de travail. >> Si systemd était _juste_ un système >> de démarrage, je n'aurais a priori rien contre s'il était bien >> ficelé. > Je ne sais pas à quel point il est mal ficelé. Moi ce que je sais, c'est > que ça marche bien chez moi. Ce n'est pas parce que ça marche chez toi que ça marche partout. La preuve est mince. > Ce que je vois, c'est que, ce après quoi tu > râles, j'ai l'impression que ça se résume en trois trucs : > - le manque de fiabilité des montés de versions. Quand tu me parles des > fichiers de configuration mal gérés par debian, je me demande à quel > point le sujet ne vient pas plus de debian que de systemd. Parce que > si les options des fichiers de conf que tu ne modifies pas sont > changées à chaque montée de version, ceci peut expliquer cela. Je t'ai parlé _d'un paquet_ bien spécifique (tomcat pour ne pas le citer). Ce qui est inadmissible n'est pas qu'il y ait eu une erreur dans le paquet en question. Mais qu'une fois la solution apportée, il n'ait fallu qu'un changement de systemd pour que ça ne fonctionne plus normalement. > - le mélange entre les confs de SysV et de systemd. Pareil, quand c'est > sorti, systemd devait probablement bien avoir besoin de certaines > parties de SysV, mais depuis j'ai tendance à croire que systemd n'a > absolument plus besoin de SysV. Est-ce que tu sais lire ? Je me contrefiche que systemd puisse utiliser (ou non d'ailleurs) les scripts de SysV. Le problème est qu'il intercepte les exécutions de scripts pour les remplacer par ses modules, ce qui fait que tu ne sais jamais ce qu'il exécute ou comment il le fait. /etc/init.d/trucmuche restart va exécuter /lib/systemd/system/trucmuche à moins qu'il ne s'agisse de /lib/systemd/user/trucmuche, de /etc/systemd/system/trucmuche ou encore /etc/systemd/user/trucmuche voire une réinterprétation de /etc/init.d/trucmuche lors de l'initialisation de systemd en tant que processus init ! Et dans certains version du bouzin, cette réinterprétation est... folklorique pour rester gentil. Je passe sous silence des outils comme Zoneminder qui utilisent maintenant systemd directement depuis les scripts Perl. Durant quelques mois, il a fallu virer les appels à systemd, ces appels faisant planter zoneminder ! Une bonne façon de faire aurait été de ne pas surcharger les scripts /etc/init.d. Mais non, ce n'est pas Michu compliant et d'avoir une API à peu près stabilisée. Là, c'est tout le contraire, on a une brique pour essuyer les plâtres. > Donc, si les deux se marchent sur les > pieds, c'est peut-être parce que debian essaye de les faire cohabiter > tant bien que mal. Pareil, si c'est le cas, c'est pas de la faute de > systemd si debian n'arrive pas à les faire cohabiter, surtout si c'est > pas utile. C'est surtout la faute d'un système d'initialisation particulièrement foireux. Il ne faudrait surtout pas se voiler la face. > - tu as quand mêmes des besoins particulièrement spécifiques. Si debian > a du mal à gérer la cohabitation entre systemd et SysV, je ne suis pas > surpris qu'ils n'aient pas testés tes cas particulier. Pareil, c'est > pas non plus de la faute de systemd si c'est debian qui n'a pas testé > tes cas particuliers. Pardon ? C'est la faute de systemd et de personne d'autre si on ne sait plus où se trouve la configuration réelle de ce qui est effectivement lancé. > Je ne suis pas trop sûr de comprendre. Les cas que tu m'as montrés sont > des exemples super particuliers. Tu veux dire que tu as généralisé ces > cas particuliers ? Ce sont des exemples parmi d'autres. Lorsque tu utilises un poste diskless, la liste des bugs de systemd est longue comme un jour sans pain. Tu es à peu près sûr qu'à chaque nouvelle version du bouzin tu te retrouves avec de nouveaux bugs à contourner. > Ça, c'est peut-être une partie du problème. Avant, l'embarqué, ils > développaient tout parce que les ressources étaient limités. Maintenant, > on met un Linux dedans parce que les ressources ont augmentés et c'est > plus facile. Après, que les distributions grand public ne soient pas > prévues pour faire de l'embarqué, oui, je veux bien te croire. Aujourd'hui, les gens sérieux virent surtout Linux qui est devenu un grand n'importe quoi en terme de consommation de ressources voire de fiabilité (et, franchement, ce n'est pas volé du tout). J'ai eu plusieurs milliers d'équipements dans la nature qui ont gardé un bug critique dans le noyau parce qu'on n'a _jamais_ réussi en labo à mettre à jour les systèmes à distance sans envoyer un technicien (systemd se vautrait à l'extinction et ne redémarrait jamais le système). C'est parfaitement inacceptable et ce n'est pas un problème de ressource ou d'embarqué, c'est un problème systemd (API mouvantes, attente sur des ressources qui n'existent plus et j'en passe !). [..] > il y ait eu un bug critique non corrigé pendant des années. J'ai vu des > mecs qui programment en ADA pour de l'embarqué et c'est pareil, il était > pas inquiet pour les bugs. La difficulté c'était la compilation. Tu veux mes échanges de mail avec le support du fondeur de l'iMX-6 ? Il avait du mal à sortir un noyau 3.0 lorsque le 4.0 était déjà sortir et un noyau officiel plantait lamentablement. Donc tu prends le noyau développé et supporté par le fondeur sauf à réécrire le tout. Sur processeur MIPS, c'est encore plus drôle à tel point que je ne les utilise plus (plantages aléatoires même avec la distribution empaquetée par le fondeur). On n'est pas en train de parler de tests écrit dans tel ou tel langage, mais du système en lui-même. Et c'est d'autant plus difficile que certains CPU sont bourrés de bugs ou de fonctionnalités foireuses (le Leon4 est un bon exemple avec son contrôleur PCI). Sans le support du fondeur, tu ne peux strictement rien faire parce que les composants ne se comportent pas vraiment comme attendu. > J'ai pas dit que c'est sytemd qui l'a inventé. À partir du moment où > rien n'est centralisé pour le gérer, chaque matériel doit être géré > à l'unité (éventuellement en groupe par exemple CUPS pour les > imprimantes). Non. > À partir du moment où c'est pris en charge en central, ça > simplifie la vie de celui qui fabrique un matériel (il n'a qu'à définir > comment il doit être initialisé) et de celui qui l'utilise. >> OK, ça c'est bizarre. Que systemd ne gère pas bien l'ordre de démarrage, > je le veux bien, que systemd soit responsable du blocage, je suis moins > sûr. Systemd t'indique des temps d'attente maximum. Sauf que pour certaines tâches ce temps peut être infini (et même en rajoutant un temps max dans la conf, ça n'est pas forcément pris en compte, il ne faut pas oublier que systemd sait mieux que toi ce qui est bon pour toi). >>> D'après ce que je comprends de la conception, c'est que le but est >>> justement de ne pas avoir s'énerver avec l'ordonnanceur puisque tout >>> est lancé en même temps et si l'un est pas prêt, le noyau catch les >>> messages en attendant que l'autre soit prêt. >> Et c'est justement le problème. > Problème pour serveur et embarqué, je veux bien. Pour poste de travail, > je n'ai rien vu. Ce n'est pas parce que tu n'as rien vu que ces problèmes n'existent pas. Je devrais faire une liste des problèmes rencontrés sur poste de travail, juste histoire de rigoler. Rien que l'aspect diskless est un nid à merde avec systemd. >> Une explosion de consommation de ressources, de PID... > Pour les ressources, je ne sais pas. Une fois que tout est démarré, le > noyau libère son cache et les ressources sont libérées. Ahah ! Si tu le dis. Tiens, systemd va lancer anacron au moins sur debian. Lequel va joyeusement lancer des foultitudes de apt machin chose. Là où ça passe très vite _séquentiellement_, ça peut prendre plusieurs dizaines de minutes sur un disque NFS attaqué en parallèle. Par ailleurs, systemd ne libère pas toujours son cache (disons que ça dépend des versions). > Pour le nombre de PID, faut se mettre d'accord. Soit c'est la > philosophie Unix de la séparaion des tâches et ça donne une augmentation > des PID. Soit on a un truc monolithique qui fait tout avec un seul PID. > Une augmentation du nombre de PID est plutôt une bonne nouvelle pour > moi, ça veut dire que c'est moins monolithique que ce qui est annoncé. Là encore, je me contrefiche du nombre de PID dans l'absolu. Le problème de l'explosion des PID, c'est la consommation des ressources (nombre de fichiers ouverts, temps CPU au sens temps système et non utilisateur...). Lorsque tu travailles sur des disques réseau, tu peux mettre à genou un serveur NFS avec systemd. Si jamais ton serveur NFS travaille avec 128 threads (TCP), tu t'apercevras assez rapidement que la charge y monte jusqu'à plus de 100 ! Pour avoir quelque chose d'utilisable, j'ai dû limiter le nombre de threads du serveur NFS à 16 quitte à ce que les clients se prennent un coup de pied aux fesses. Au-delà, c'était l'engorgement assuré (avec un seul Linux utilisant systemd, j'ai fait des tests). Tu me diras que tu n'en a rien à faire, c'est une configuration spécifique. Certes. Très certes, même. Mais ce qui se passe sur un réseau se passe exactement de la même façon à l'intérieur d'une seule machine. On le voit juste moins. [..] > pas comprendre. Si des mainteneurs de distribution veulent changer leur > shell par défaut, il y a plein de trucs à prendre en compte qui n'ont > pas lieu d'être. Parce que tu crois sérieusement que ce n'est pas le cas avec les modules systemd ? Dans certains configurations, pour certains daemons bien spécifiques, le module systemd appelle des bouts de shell ou de perl pour reconfigurer à la volée le fonctionnement de systemd et contourner certains bugs ou certaines limitations ! Tu parles d'une solution propre ! Des scripts bien ficelés seraient bien plus efficaces. > D'abord, ce ne sont pas forcément les mêmes qui vont faire la deuxième > étape (s'il y en a une, je ne suis pas visionnaire c'est une > possibilité). Les premiers n'ont pas forcément prévu de basculer. > Ensuite, Ça peut être plus facile de procéder par étape. > Enfin, il y a toujours une partie retour d'expérience. C'est facile une > fois que le boulot est fini de voir comment il aurait fallu faire. C'est > rarement tout bon ou tout mauvais. Mais c'est quand on a fini qu'on peut > voir les amélioration : en apprenant de ses erreurs. Lorsqu'il y a eu une bataille pour savoir si systemd était bon ou mauvais, j'ai pris la peine de regarder le truc obectivement. Ma conclusion était que ce truc était mauvais par design et mon avis n'a pas changé depuis. Je m'y suis pourtant mis parce que je n'ai pas eu le choix. Tout ce que je pensais du bouzin à l'époque est toujorus d'actualité. Linux avec ce machin a intégré tous les défauts reprochés à Windows il y a quinze à vingt ans et risque de le payer très cher. Ce n'est pas un problème, dans l'embarqué je vois de plus en plus de choses tournant autour de xBSD, de micro-noyau de type L4. Pas besoin de se taper 4Go de mémoire et tout un OS obèse (consomamteur d'énergie). On trouve encore ce genre de chose (le petit bleu qui arrive pour concevoir un compteur électrique avec 8Go de mémoire, un JVM Java et plein d'autres choses qui pourraient être faites avec quelques lignes d'assembleur 6809 ou un ATmega et quelques Ko de mémoire directement en C), mais de plus en plus rarement. Heureusement. JKB |
|
|
Le 06-06-2020, Yliur <yliur> a écrit :
> Le Fri, 05 Jun 2020 10:21:44 +0000, Stéphane CARPENTIER a écrit : >> Ah bah désolé... :) > Personnellement quand arch est passé à systemd j'ai appris quelques > commandes, arrêté d'utiliser "/etc/rc.d/service restart" au profit de > "systemctl restart service" et ça s'est un peu arrêté là... > J'ai suivi quelques discussions sur systemd mais pour ce que j'en fais ça > ne change pas grand chose à ma vie. Moi, c'est un peu pareil, sauf que pour initialiser le bousin, il fallait que je cherche un peu. Ensuite, pour savoir mieux, il faudrait que je me plonge dedans, mais ce n'est pas ma priorité. Mais vu certaines critiques, j'ai cherché à en savoir un peu plus mais sans avoir été convaincu et tu me montres qu'il y a des avantages que je n'avais pas vus. Si je n'arrive pas à croire que tout est mieux que systemd sans raison, j'ai du mal à croire que la cabale contre systemd soit aussi totalement dénuée de raison. Parce qu'il y a de vrais systèmes alternatifs qui existent. Ils n'ont pas pu être créés pour des raisons uniquement passionnelles. > Mais au moment de l'installation d'arch, tu suis la page d'installation > et pas celle de systemd, non ? Qu'est-ce que tu as besoin de savoir sur > systemd quand tu fais une installation arch ? Oui, enfin quand tu as suivi la page d'installation d'Arch, t'es pas à la fin. Il faut configurer le réseau par exemple. Par défaut, la prise RJ45 est OK, mais si tu veux avoir le choix entre le wifi et la prise ethernet, c'est un peu plus subtil (j'avais pas de laptop avant, juste un fixe). Ensuite, tu as le ntp à configurer aussi. Il faut comprendre ce qui a été fait et ce qui reste à faire. Il y a aussi l'interface graphique à installer si besoin, mais là, systemd n'est pas impliqué (enfin s'il l'est, ça a été transparent pour moi). > Pour moi quand tu fais ton installation archlinux sans savoir exactement > où tu vas ni connaître les outils, tu suis la procédure sans trop en > dévier et ça te permet de savoir un peu que telle ou telle partie se > configure à tel ou tel endroit (et aussi d'avoir une machine > fonctionnelle). Oui, mais Archlinux est une distribution minimale. C'est fonctionnel mais pour être vraiment utilisable, il reste des trucs à faire. Je ne me plains pas, je savais pourquoi j'avais choisi Archlinux et j'ai eu ce que j'ai voulu. Maintenant, ça marche bien depuis un certain temps et je suis satisfait d'avoir fait ce choix. Je dis juste que quand je dois découvrir des outils (pacman et systemd), et faire des choix que j'ignorais (xorg/wayland et gestion du wifi) au moment de l'installation, j'ai pas le temps d'approfondir. Et le problème du wiki Arch, c'est qu'il explique quoi faire quand tu sais ce que tu dois faire. Mais, quand tu ne sais pas trop ce que tu dois faire, il te renvois vers des liens qui te renvoient vers des liens et ça part un peu dans tous les sens. Après, pour d'autres trucs, comme la découverte de i3, vu que je venais de wmii j'ai pas été trop dépaysé. Pour sa configuration, c'est pas très grave si c'est long de se plonger dedans car j'avais un sytème opérationnel. Je pouvais prendre mon temps pour tacler les sujets un par un. Mais pour l'installation, c'est un peu différent. |
|
|
Stéphane CARPENTIER , dans le message
<slrnrdlgvj.7b7l.sc>, a écrit : > Si c'est très compliqué à > configurer (j'en sais rien) ça peut ne pas être agréable. Ça se configure dans /etc/systemd/logind.conf, qui fait par défaut ici 37 lignes, dont : [Login] #NAutoVTs=6 #ReserveVT=6 #KillUserProcesses=no #KillOnlyUsers= #KillExcludeUsers=root Et le man dit : KillUserProcesses= Takes a boolean argument. Configures whether the processes of a user should be killed when the user logs out. If true, the scope unit corresponding to the session and all processes inside that scope will be terminated. If false, the scope is "abandoned", see systemd.scope(5), and processes are not killed. Defaults to "no", but see the options KillOnlyUsers= and KillExcludeUsers= below. In addition to session processes, user process may run under the user manager unit user@.service. Depending on the linger settings, this may allow users to run processes independent of their login sessions. See the description of enable-linger in loginctl(1). Note that setting KillUserProcesses=yes will break tools like screen(1) and tmux(1), unless they are moved out of the session scope. See example in systemd-run(1). Je te laisse me dire : est-ce qu'un bug de systemd a cassé screen, ou bien est-ce que des gens ne lisent pas la doc ? |
|
|
Stéphane CARPENTIER , dans le message
<slrnrdmpu2.qo.sc>, a écrit : > Si je n'arrive pas à croire que tout est mieux que systemd sans raison, > j'ai du mal à croire que la cabale contre systemd soit aussi totalement > dénuée de raison. Ici, tu as affaire à un phénomène sociologique classique : il n'y a pas besoin d'être d'accord pour être contre ensemble. Pour certains, je pense que l'explication est à trouver dans le fait que SysV init est tellement mauvais, un assemblage mal ficelé de script shell fragiles. (Le shell est un langage intrinsèquement fragile.) Donc réaliser quelque chose d'efficace dans ce cadre relève de compétences arcanes. Or les compétences arcanes, elles sont difficiles à acquérir et peu généralisables. Avoir investi des efforts considérables dans des compétences qui deviendraient inutiles si le contexte changeait, c'est une recette pour se trouver en dissonance cognitive et rejeter le changement, même vers le progrès. |
|
|
Le 06-06-2020, JKB <jkb> a écrit :
> Le 05 Jun 2020 22:05:39 GMT, Stéphane CARPENTIER <sc> > écrivait : > Remarque bien, il n'y a aucune raison que les problèmes rencontrés > ailleurs que sur un poste de travail ne finissent pas par arriver > sur un poste de travail. Oui, les problèmes rencontrés hors poste de travail peuvent arriver sur un poste de travail plus tard. Mais si les problèmes rencontrés sur un serveur ou sur de l'embarqué sont dus à des spécificités pour améliorer le poste de travail, c'est pas obligatoire que ça arrive. >> Je ne sais pas à quel point il est mal ficelé. Moi ce que je sais, >> c'est que ça marche bien chez moi. > Ce n'est pas parce que ça marche chez toi que ça marche partout. La > preuve est mince. Ça ne prouve pas que ça marche partout, ça prouve juste que ça peut marcher. Et comme beaucoup de grosses distributions ont basculé sur systemd, c'est que globalement, ça doit marcher sur pas mal de postes de travail. Après, toi, tu choisis une distribution grand public pour faire de l'embarqué parce que c'est mieux pour les remontées de bugs. Je le comprends, mais tu ne peux pas être surpris que les distributions grand public utilisent des fonctionnalités orientées grand public. Même si ces fonctionnalités sont contradictoires avec tes besoins. Tu veux contrôler le séquencement du boot alors que par design systemd parallélise tout. Ben oui, je comprends que ça te gêne. Je ne dis pas que je m'en fous, mais je dis que ça m'emmerderait de ne pas pouvoir utiliser cette fonctionnalité sur mon poste de travail parce que ça marche pas sur de l'embarqué. Parce que l'avantage de tout lancer en même temps, c'est qu'il n'y a pas besoin de s'énerver à chercher l'ordre des lancement des différents scripts. Au boulot, il n'y a pas un seul serveur avec Archlinux dessus. Ce n'est pas parce que j'ai choisis ça pour moi que je vais leur conseiller de l'utiliser : ce serait idiot. Archlinux est une distribution minimale et en soi c'est compatible serveur. Mais c'est aussi une distribution rolling bleeding edge et ça, c'est totalement incompatible avec une installation sur serveur. Donc Archlinux est une distribution poste de travail et d'y mettre systemd, qui est orienté poste de travail, me semble un bon choix. Que sur des systèmes orienté serveur/embarqué je ne suis pas sûr que le choix soit aussi pertinent, mais ce n'est pas mon problème : c'est le problème de ceux qui maintiennent/installent des distributions et des serveurs. Ce que je sais, c'est qu'au boulot, les problèmes que nous avons avec les serveurs, il y en a et ce n'est pas sur systemd que les gens râlent. >> Problème pour serveur et embarqué, je veux bien. Pour poste de travail, >> je n'ai rien vu. > Ce n'est pas parce que tu n'as rien vu que ces problèmes n'existent > pas. Bien sûr que non, mais sur la cabale j'ai vu sur systemd, il y a des critiques justifiées sur sa conception. Si j'étais le seul au monde chez qui ça marche parce que j'ai du bol, j'aurais vu des liens vers l'horreur sans nom qu'est systemd dans la vraie vie. Oui, il y a des gens qui ont des problèmes avec. Mais pas plus qu'avec les autres systèmes. > Là encore, je me contrefiche du nombre de PID dans l'absolu. Le > problème de l'explosion des PID, c'est la consommation des > ressources (nombre de fichiers ouverts, temps CPU au sens temps > système et non utilisateur...). Comme je l'ai déjà dit, sur un poste de travail moderne, avec KDE/Gnome/Plama/Compiz/FireFox/whatever je ne peux pas croire que ce soit systemd qui bouffe toutes les ressources. |
|
|
Le 06 Jun 2020 10:41:26 GMT,
Stéphane CARPENTIER <sc> écrivait : > Le 06-06-2020, JKB <jkb> a écrit : > Oui, les problèmes rencontrés hors poste de travail peuvent arriver sur > un poste de travail plus tard. Mais si les problèmes rencontrés sur > un serveur ou sur de l'embarqué sont dus à des spécificités pour > améliorer le poste de travail, c'est pas obligatoire que ça arrive. >> Ça ne prouve pas que ça marche partout, ça prouve juste que ça peut > marcher. Il y a plein de choses qui peuvent marcher. Ce qui rate peut aussi marcher de temps en temps. C'est assez shadokien comme logique. Pour fixer les idées : [..] 1224 open, 5016 closed. Je te conseille de lire les premiers, il y en a des croquignolets et on se demande même comment ça peut fonctionner sur un poste de travail (le coup des baux DHCP est amusant, enfin peut-être, faut juste ne pas être concerné !). Ça aussi, c'est éloquent : [..] > Et comme beaucoup de grosses distributions ont basculé sur > systemd, c'est que globalement, ça doit marcher sur pas mal de postes de > travail. Chez Debian, la raison n'était pas de fonctionner ou pas. Il y a eu des discussions à n'en plus finir et la courte majorité qui a voté pour systemd l'a fait pour des raisons de maintenabilité parce que systemd était utilisé par tout un tas de logiciels (même débat que pour HAL en son temps). L'équipe de devs ne voulait pas perdre de l'énergie à repousser systemd comme init puisque de toute façon, si ils le repoussaient par la porte, il entrerait par la fenêtre. > Après, toi, tu choisis une distribution grand public pour faire de > l'embarqué parce que c'est mieux pour les remontées de bugs. Je le > comprends, mais tu ne peux pas être surpris que les distributions grand > public utilisent des fonctionnalités orientées grand public. Même si ces > fonctionnalités sont contradictoires avec tes besoins. Ah non, je n'utilise plus de distribution grand public depuis que systemd a montré le bout de son nez. Je taille aujourd'hui des BSD à la serpe. Bien plus efficaces. Et lorsque ce n'est pas supporté par NetBSD, je n'utilise plus les architectures en question. J'ai eu beaucoup trop de problème avec le CPU magique à tout faire qui est vaguement supporté par une équipe chez un fondeur. > Tu veux contrôler le séquencement du boot alors que par design systemd > parallélise tout. Ben oui, je comprends que ça te gêne. Je ne dis pas > que je m'en fous, mais je dis que ça m'emmerderait de ne pas pouvoir > utiliser cette fonctionnalité sur mon poste de travail parce que ça > marche pas sur de l'embarqué. Parce que l'avantage de tout lancer en > même temps, c'est qu'il n'y a pas besoin de s'énerver à chercher l'ordre > des lancement des différents scripts. Le problème, c'est que tu veux absolument voir le problème par le petit bout de la lorgnette. Les problèmes que l'on rencontre dans l'embarqués sont identiques sur des réseaux par design (parce que systemd est mal conçu dès le départ). Encore une fois, sur mon réseau, je n'ai que des postes diskless (parce qu'en maintenance, c'est bien plus efficace). Une machine crame, je remplace la machine par une autre et je change l'adresse MAC dans la conf de tftpd sur le serveur. Ça me simplifie aussi toutes les sauvegardes et archivages. Dans cette situation, systemd est une calamité. Lorsque je pars en déplacement quinze jours et que j'éteins mon poste de travail, il lui faut souvent une bonne demi-heure pour redémarrer. C'est juste un i7 avec 32 Go de mémoire. Une toute petite machine sous-dimensionnée ! La conception même de systemd introduit des goulots d'étranglement partout, ouvre des fichiers dans tous les sens. Ça passe à peu près sur une machine qui a tout en local, mais dès que ce n'est plus le cas, ça devient la fête. Cerise sur le gâteau, lorsque je redémarre une machine munie de systemd, je peux être sûr que mon épouse qui travaille sur un poste FreeBSD (diskless aussi) hurlera parce que toutes les ressources sont bouffées par systemd sur le serveur NFS et que ça lui bloque tous les accès disques. Pas question d'augmenter le nombre de threads côté serveur, parce que les latences augmentent exponentiellement. Il vaut mieux qu'un client se prenne un refus pour éviter d'engorger le serveur. [..] > distributions et des serveurs. > Ce que je sais, c'est qu'au boulot, les problèmes que nous avons avec > les serveurs, il y en a et ce n'est pas sur systemd que les gens râlent. Je n'ai jamais dit que ça ne fonctionnait pas dans certains cas, je prétends que c'est une catastrophe industrielle et un nid à emmerdes sans nom. Je prétends qu'on passe beaucoup plus de temps à avoir une configuration à peu près fiable avec systemd qu'avec un init de type SysV ou BSD. > Bien sûr que non, mais sur la cabale j'ai vu sur systemd, il y a des > critiques justifiées sur sa conception. Si j'étais le seul au monde chez > qui ça marche parce que j'ai du bol, j'aurais vu des liens vers > l'horreur sans nom qu'est systemd dans la vraie vie. Oui, il y a des > gens qui ont des problèmes avec. Mais pas plus qu'avec les autres > systèmes. Va donc lire des rapports de bugs de systemd. Lorsqu'un outil a autant de rapports d'erreurs (et autant de rapports d'erreurs sur des effets de bord), c'est qu'il est mal conçu par design. Et par design, comme c'est un truc à tout faire, il y a beaucoup plus de problèmes qu'avec un système comme SysV (on fait un ls dans un répertoire, on trie par ordre alphabétique et on lance les scripts un a un) ou rcorder (on balaie un répertoire et on trie en fonction de balises dans l'en-tête des fichiers). > Comme je l'ai déjà dit, sur un poste de travail moderne, avec > KDE/Gnome/Plama/Compiz/FireFox/whatever je ne peux pas croire que ce > soit systemd qui bouffe toutes les ressources. Soyons joueur... Configuration : i7, 32 Go de mémoire. Heureusement qu'il y a 32 Go de mémoire parce que, je viens de vérifier, le processus de PID 1 consomme 170,6 Mo de mémoire. Et il n'est même pas verrouillé en mémoire ! Depuis le 13 mai, on se demande ce qu'il a fait en consommant 1h04 de temps CPU. Cerise sur le gâteau, un lsof montre que systemd a actuellement la bagatelle de 2575 fichiers ouverts directement ou indirectement (le nombre de trucs liés avec libsystemd est assez impressionnant) ! Sur mon serveur (NetBSD 9.0) qui a redémarré le 21 mai dernier, init a consommé 27,01 s de temps CPU et occupe 19 Mo. Il y a beaucoup plus de choses lancées sur le BSD que sur mon poste client (qui utilise Windowmaker si on veut être précis). JKB |
|
|
JKB , dans le message <slrnrdn39v.2oi7v.jkb>, a
écrit : > (le coup des baux DHCP est amusant, enfin peut-être, faut > juste ne pas être concerné !). Oui, il est amusant, ce bug-report : - On signale que la perte des baux entraîne la coupure des connexions TCP, ce qui n'est en réalité pas le cas par défaut, il faut avoir un firewall moisi pour que ça arrive. (Google a réussi à en faire le défaut dans Android, mais bon.) - En fait c'est juste une option. |
|
|
Le 06-06-2020, Nicolas George <nicolas$george> a écrit :
> Stéphane CARPENTIER , dans le message ><slrnrdmpu2.qo.sc>, a écrit : >> Si je n'arrive pas à croire que tout est mieux que systemd sans >> raison, j'ai du mal à croire que la cabale contre systemd soit aussi >> totalement dénuée de raison. > Ici, tu as affaire à un phénomène sociologique classique : il n'y a > pas besoin d'être d'accord pour être contre ensemble. Oui, mais de là à créer un système concurrent genre openrc juste parce que systemd bouscule trop nos habitudes, ça va plus loin que le phénomène sociologique classique. > Or les compétences arcanes, elles sont difficiles à acquérir et peu > généralisables. Avoir investi des efforts considérables dans des > compétences qui deviendraient inutiles si le contexte changeait, c'est > une recette pour se trouver en dissonance cognitive et rejeter le > changement, même vers le progrès. Initialement, c'était un peu mes raisons. Je n'ai jamais eu les compétences arcanes mais j'arrivais à faire ce que je voulais et je comprenais globalement comment ça marchait. Avec ubuntu j'ai eu systemd, mais comme il faisait tout tout seul, je n'ai jamais eu à me poser de question. Puis, avec Archlinux, j'étais franchement paumé en arrivant sur systemd. Donc, quand en cherchant de l'aide je voyais une cabale contre systemd. Je me suis dit que j'allais pas investir trop de temps à comprendre systemd. Je me suis dis qu'il n'y avait qu'à le faire tourner, puis chercher mieux et le dégager. Sauf que j'ai vu aucun argument expliquant pourquoi les alternatives sont mieux. Au contraire, les arguments me montrent que c'est mieux que ce que je croyais et que ça peut valoir le coup d'investir du temps à comprendre comment ça marche. Vu que je ne demandais qu'à être converti, ça aurait dû être facile de me montrer mieux. Vu que je n'ai pas trouvé, je vais considérer qu'en attendant il n'y a pas mieux et que ce n'est pas si mal que ça. L'un de mes soucis principaux, c'est que je voulais comprendre exactement dans quel ordre les process étaient lancés. Et ça me gonflait de ne pas le trouver. Sauf qu'en cherchant sur la cabale, j'ai trouvé plus d'explications de conceptions de systemd que techniques. Je ne comprends toujours pas dans quel ordre c'est lancé mais je comprends surtout que c'est pas important pour un poste de travail. |
|
|
Discussions similaires | |
Redhat Entreprise ou maj de Redhat 9
|
|
RedHat ES3 et RedHat classique
|
|
Gel de ma Redhat
|
|
4 cds redhat EL 3.0
|
Fuseau horaire GMT +2. Il est actuellement 13h06. | Privacy Policy
|