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.