Redhat

JKB

06/06/2020 à 14:34

Le 06 Jun 2020 10:41:26 GMT,
Stéphane CARPENTIER écrivait :

Le 06-06-2020, JKB a écrit :
Le 05 Jun 2020 22:05:39 GMT, Stéphane CARPENTIER
écrivait :
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.

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.

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 :
https://github.com/systemd/systemd/issues
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 :
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dist=unstable

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.

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.

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.

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.

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).

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...).

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
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

Le 06 Jun 2020 10:41:26 GMT,
Stéphane CARPENTIER <sc@fiat-linux.fr> écrivait :

Le 06-06-2020, JKB <jkb@koenigsberg.invalid> a écrit :

Le 05 Jun 2020 22:05:39 GMT, Stéphane CARPENTIER <sc@fiat-linux.fr>
écrivait :

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.

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.

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 :

https://github.com/systemd/systemd/issues
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 :
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dist=unstable

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.

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.

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.

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.

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).

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...).

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

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

Vous avez filtré cet utilisateur ! Consultez son message

Le 06 Jun 2020 10:41:26 GMT,
Stéphane CARPENTIER écrivait :

Le 06-06-2020, JKB a écrit :
Le 05 Jun 2020 22:05:39 GMT, Stéphane CARPENTIER
écrivait :
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.

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.

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 :
https://github.com/systemd/systemd/issues
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 :
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dist=unstable

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.

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.

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.

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.

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).

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...).

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
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

Nicolas George

06/06/2020 à 14:41

JKB , dans le message , 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.

Stéphane CARPENTIER

06/06/2020 à 15:03

Le 06-06-2020, Nicolas George <nicolas$ a écrit :

Stéphane CARPENTIER , dans le message
, 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.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

Le 06-06-2020, Nicolas George <nicolas$george@salle-s.org> a écrit :

Stéphane CARPENTIER , dans le message
<slrnrdmpu2.qo.sc@scarpet42p.localdomain>, 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.

--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

Vous avez filtré cet utilisateur ! Consultez son message

Le 06-06-2020, Nicolas George <nicolas$ a écrit :

Stéphane CARPENTIER , dans le message
, 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.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

Stéphane CARPENTIER

06/06/2020 à 15:09

Le 06-06-2020, Nicolas George <nicolas$ a écrit :

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 ?

J'avais dit dès le début que je n'avais pas lu la doc sur ce truc en
particulier, donc pour ça je fais partie des gens qui ne lisent pas la
doc, mais je n'avais pas d'avis non plus.
Maintenant que je vois la partie indiquée, ça me semble plutôt pas mal.
Tu peux demander à tuer tous tes process par défaut. Et en cas de besoin
particulier, tu lances expressément un process qui ne sera pas tué.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

Yliur

06/06/2020 à 15:58

Le Sat, 06 Jun 2020 12:34:07 +0000, JKB a écrit :

Pour fixer les idées :
https://github.com/systemd/systemd/issues 1224 open, 5016 closed.

Sauf que dans la liste il y a des choses qui vont du bug à la demande
d'amélioration, en passant par des questions limite forum (du type "je ne
vois pas comment faire ça", sans que ça ait forcément (encore) été trié
comme demande d'amélioration)
Si on ne considère que l'étiquette "bug", on a ça : 89 open, 829 closed.
Il se peut qu'en réalité ce soit un peu plus, mais prendre le chiffre
brut sans même regarder ce qu'il y a dedans c'est de la mauvaise foi
quand même...

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 !

Chez moi aussi, sauf que top dit ça :
VIRT : 175288
RES : 5292
%MEM : 0,0
Donc si je comprends bien, 170Mo de mémoire virtuelle mais seulement 5Mo
de mémoire réservée. Ce qui peut aussi bien signifier que plein de code
est associé à la mémoire virtuelle du processus mais que ce n'est pas
forcément chargé en mémoire.
Par "verrouillé en mémoire", tu veux dire que le code devrait rester en
mémoire en permanence ? Auquel cas j'imagine que c'est moins intéressant
s'il y en a beaucoup. Mais pourquoi le fait qu'un bout de code du système
d'initialisation qui ne sert jamais reste en mémoire est plus pertinent
que pour n'importe quel processus ?

Depuis le 13 mai, on se demande ce qu'il a fait en consommant
1h04 de temps CPU.
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).

Pareil ici, mais ça représente environ 2 minutes par jour.
Ta comparaison avec NetBSD, c'est à périmètre équivalent ? Par exemple
systemd gère des journaux, le temps de traitement lui est sans doute
attribué.

Le Sat, 06 Jun 2020 12:34:07 +0000, JKB a écrit :

Pour fixer les idées :

https://github.com/systemd/systemd/issues 1224 open, 5016 closed.

Sauf que dans la liste il y a des choses qui vont du bug à la demande
d'amélioration, en passant par des questions limite forum (du type "je ne
vois pas comment faire ça", sans que ça ait forcément (encore) été trié
comme demande d'amélioration)

Si on ne considère que l'étiquette "bug", on a ça : 89 open, 829 closed.

Il se peut qu'en réalité ce soit un peu plus, mais prendre le chiffre
brut sans même regarder ce qu'il y a dedans c'est de la mauvaise foi
quand même...

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 !

Chez moi aussi, sauf que top dit ça :
VIRT : 175288
RES : 5292
%MEM : 0,0

Donc si je comprends bien, 170Mo de mémoire virtuelle mais seulement 5Mo
de mémoire réservée. Ce qui peut aussi bien signifier que plein de code
est associé à la mémoire virtuelle du processus mais que ce n'est pas
forcément chargé en mémoire.

Par "verrouillé en mémoire", tu veux dire que le code devrait rester en
mémoire en permanence ? Auquel cas j'imagine que c'est moins intéressant
s'il y en a beaucoup. Mais pourquoi le fait qu'un bout de code du système
d'initialisation qui ne sert jamais reste en mémoire est plus pertinent
que pour n'importe quel processus ?

Depuis le 13 mai, on se demande ce qu'il a fait en consommant
1h04 de temps CPU.

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).

Pareil ici, mais ça représente environ 2 minutes par jour.

Ta comparaison avec NetBSD, c'est à périmètre équivalent ? Par exemple
systemd gère des journaux, le temps de traitement lui est sans doute
attribué.

Vous avez filtré cet utilisateur ! Consultez son message

Le Sat, 06 Jun 2020 12:34:07 +0000, JKB a écrit :

Pour fixer les idées :
https://github.com/systemd/systemd/issues 1224 open, 5016 closed.

Sauf que dans la liste il y a des choses qui vont du bug à la demande
d'amélioration, en passant par des questions limite forum (du type "je ne
vois pas comment faire ça", sans que ça ait forcément (encore) été trié
comme demande d'amélioration)
Si on ne considère que l'étiquette "bug", on a ça : 89 open, 829 closed.
Il se peut qu'en réalité ce soit un peu plus, mais prendre le chiffre
brut sans même regarder ce qu'il y a dedans c'est de la mauvaise foi
quand même...

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 !

Chez moi aussi, sauf que top dit ça :
VIRT : 175288
RES : 5292
%MEM : 0,0
Donc si je comprends bien, 170Mo de mémoire virtuelle mais seulement 5Mo
de mémoire réservée. Ce qui peut aussi bien signifier que plein de code
est associé à la mémoire virtuelle du processus mais que ce n'est pas
forcément chargé en mémoire.
Par "verrouillé en mémoire", tu veux dire que le code devrait rester en
mémoire en permanence ? Auquel cas j'imagine que c'est moins intéressant
s'il y en a beaucoup. Mais pourquoi le fait qu'un bout de code du système
d'initialisation qui ne sert jamais reste en mémoire est plus pertinent
que pour n'importe quel processus ?

Depuis le 13 mai, on se demande ce qu'il a fait en consommant
1h04 de temps CPU.
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).

Pareil ici, mais ça représente environ 2 minutes par jour.
Ta comparaison avec NetBSD, c'est à périmètre équivalent ? Par exemple
systemd gère des journaux, le temps de traitement lui est sans doute
attribué.

Stéphane CARPENTIER

06/06/2020 à 16:58

Le 06-06-2020, JKB a écrit :

Le 06 Jun 2020 10:41:26 GMT,
Stéphane CARPENTIER écrivait :
Ç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 :
https://github.com/systemd/systemd/issues
1224 open, 5016 closed.

Là, tu vas dans mon sens. D'abord, c'est pas une liste de bugs, c'est
une liste de tâches. Il y a un bug reconnu comme tel. Il y a des demandes
d'évolutions. Il y a des gens un peu paumés (ce que je comprends mon
sens n'est pas de dire que systemd est d'une simplicité enfantine).
Sur la première page, il y a 25 demandes. Dont 9 demandes d'évolutions.
Il y a un bug recensé comme tel. Il y a deux demandes d'attentes
d'explications utilisateurs. En gros, sur une application stable avec un
nombre conséquent d'utilisateurs, tu peux t'attendre à 1 bug pour 10
demandes de support. Pour ce que j'en vois on en est très loin (si je
regarde la seconde page, je ne vois qu'un bug et qu'une régression).
Les applications moisies que j'ai pu voir, je t'assure que c'est
vraiment pas le même ratio.
Donc, oui, vu la cabale sur systemd, s'il y avait une foule
d'utilisateur hurlante, elle m'aurait été pointée.

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 premier qui demande comment faire pour que son laptop puisse se
mettre en veille s'il est débranché mais pas s'il est branché et que ça
doit aussi dépendre de s'il est connecté à un moniteur partagé avec un
autre ordinateur n'est quand même pas un truc banal.

(le coup des baux DHCP est amusant, enfin peut-être, faut
juste ne pas être concerné !).

Ce qui est important, c'est pas qu'il y ait des anomalies, c'est que ce
soit vitre traité. Et là, c'est traité en une dizaine de jours, c'est
pas mal.

Ça aussi, c'est éloquent :
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dist=unstable

Oui, ben qu'une testing ne soit pas stable, c'est prévu. C'est pour ça
que ça s'appelle testing. Pour moi, quand il ne trouve pas un fichier de
conf, c'est debian qui intègre mal le package : c'est pas de la faute de
systemd.

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.

Et bien c'est super alors.

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).

Tu veux dire que si le F5 c'est un bordel immonde que personne ne
maîtrise c'est à cause de systemd ? Tu veux dire que sur mon poste du
boulot, lorsque je vais sur une application Extranet, si ça rame en
traversant 3 routeurs, 5 firewall et 2 F5 c'est à cause de systemd ? On
a des problèmes de réseau super compliqués indémerdable. Je n'ai jamais
entendu de critique de systemd comme source. Le réseau du boulot est
tellement pourri que pour aller sur certaines applications sur
l'Extranet il vaut mieux utiliser son ordinateur personnel.
Alors, oui, je sais, l'architecture c'est super important. Je m'engueule
assez souvent avec des architectes et des gens de la sécurité pour savoir
quelles sont les contraintes. Et c'est marrant, mais systemd, c'est
jamais, mais alors jamais, dans la liste des sujets. C'est chez moi que
j'ai découvert ça. Quand les architectes me proposent une solution,
plein de trucs peuvent être mentionnés, mais jamais systemd ne rentre en
ligne de compte : ils s'en cognent.

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.

Je ne te parle pas de juste des cas particuliers qui tombent en marche
par chance. Je te dis que pour ce que je vois, systemd ne pose pas de
problème. Je travaille à la DSI d'une grosse entreprise. Je sais ce qui
pose problème sur nos applications. Parce que les gros problèmes j'en
entend parler. Si systemd faisait partie du TOP 100 des sujets, j'en
aurais forcément entendu parler à un moment où à un autre. Ça ne veut
pas dire qu'il n'y a aucun problème avec systemd, ça veut dire qu'ils ne
sont pas assez importants pour remonter. Et c'est vraiment loin d'être
la guerre que tu me décris.
Au boulot, le deuxième plus gros problème (après le réseau), c'est
l'obsolescence. Et encore, maintenant que tout est virtualisé, nous
n'avons plus le risque qu'il y avait il y a dix ans de devoir faire les
puces si certaines machines tombaient.
Au boulot, l'un des très gros sujet vient des interfaces entre les
systèmes. Ça, c'est problématique, ça pose plein de soucis de fiabilité
de sécurité, de plein de trucs.
Au boulot, un autre sujet sensible vient à la fois de la sensibilité des
informations pour savoir quelle sécurité appliquer dessus ainsi que la
loi RGPD. Et ça c'est très compliqué car c'est autant décisionnel que
légal que technique.
Le problème d'Oracle qui se met à faire payer java, par exemple, c'est
un vrai sujet parce que ça oblige à savoir où se trouvent les jdk sur
tous les serveurs. Le sujet de dégager les Windows 2003 qui continuent à
trainer c'est un vrai sujet. Le sujet des Red Hat 2 qui continuent à
trainer c'est un vrai sujet. Le sujet des applications mal codées qui
coûtent une fortune en maintenance, c'est un vrai sujet.
Mais le sujet de systemd, au boulot : tout le monde s'en bat les flanc.
Que ce soit pour des sauvegardes. Que ce soit pour des applications sur
le DRP, pour des applications sur le cloud, pour des applications sur
dans les centres de services. Pour des petites applications ou des gros
ERP. Pas une fois, sur tous les problèmes que j'ai pu entendre, pas une
fois quelqu'un m'a dit que c'était l'ordonnancement qui n'était pas
maîtrisé et qu'on ne pouvait pas choisir l'ordre de démarrage. Et je
vais te dire que des sujets j'en ai vu passer.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

Le 06-06-2020, JKB <jkb@koenigsberg.invalid> a écrit :

Le 06 Jun 2020 10:41:26 GMT,
Stéphane CARPENTIER <sc@fiat-linux.fr> écrivait :

Ç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 :

https://github.com/systemd/systemd/issues
1224 open, 5016 closed.

Là, tu vas dans mon sens. D'abord, c'est pas une liste de bugs, c'est
une liste de tâches. Il y a un bug reconnu comme tel. Il y a des demandes
d'évolutions. Il y a des gens un peu paumés (ce que je comprends mon
sens n'est pas de dire que systemd est d'une simplicité enfantine).

Sur la première page, il y a 25 demandes. Dont 9 demandes d'évolutions.
Il y a un bug recensé comme tel. Il y a deux demandes d'attentes
d'explications utilisateurs. En gros, sur une application stable avec un
nombre conséquent d'utilisateurs, tu peux t'attendre à 1 bug pour 10
demandes de support. Pour ce que j'en vois on en est très loin (si je
regarde la seconde page, je ne vois qu'un bug et qu'une régression).
Les applications moisies que j'ai pu voir, je t'assure que c'est
vraiment pas le même ratio.

Donc, oui, vu la cabale sur systemd, s'il y avait une foule
d'utilisateur hurlante, elle m'aurait été pointée.

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 premier qui demande comment faire pour que son laptop puisse se
mettre en veille s'il est débranché mais pas s'il est branché et que ça
doit aussi dépendre de s'il est connecté à un moniteur partagé avec un
autre ordinateur n'est quand même pas un truc banal.

(le coup des baux DHCP est amusant, enfin peut-être, faut
juste ne pas être concerné !).

Ce qui est important, c'est pas qu'il y ait des anomalies, c'est que ce
soit vitre traité. Et là, c'est traité en une dizaine de jours, c'est
pas mal.

Ça aussi, c'est éloquent :
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dist=unstable

Oui, ben qu'une testing ne soit pas stable, c'est prévu. C'est pour ça
que ça s'appelle testing. Pour moi, quand il ne trouve pas un fichier de
conf, c'est debian qui intègre mal le package : c'est pas de la faute de
systemd.

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.

Et bien c'est super alors.

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).

Tu veux dire que si le F5 c'est un bordel immonde que personne ne
maîtrise c'est à cause de systemd ? Tu veux dire que sur mon poste du
boulot, lorsque je vais sur une application Extranet, si ça rame en
traversant 3 routeurs, 5 firewall et 2 F5 c'est à cause de systemd ? On
a des problèmes de réseau super compliqués indémerdable. Je n'ai jamais
entendu de critique de systemd comme source. Le réseau du boulot est
tellement pourri que pour aller sur certaines applications sur
l'Extranet il vaut mieux utiliser son ordinateur personnel.

Alors, oui, je sais, l'architecture c'est super important. Je m'engueule
assez souvent avec des architectes et des gens de la sécurité pour savoir
quelles sont les contraintes. Et c'est marrant, mais systemd, c'est
jamais, mais alors jamais, dans la liste des sujets. C'est chez moi que
j'ai découvert ça. Quand les architectes me proposent une solution,
plein de trucs peuvent être mentionnés, mais jamais systemd ne rentre en
ligne de compte : ils s'en cognent.

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.

Je ne te parle pas de juste des cas particuliers qui tombent en marche
par chance. Je te dis que pour ce que je vois, systemd ne pose pas de
problème. Je travaille à la DSI d'une grosse entreprise. Je sais ce qui
pose problème sur nos applications. Parce que les gros problèmes j'en
entend parler. Si systemd faisait partie du TOP 100 des sujets, j'en
aurais forcément entendu parler à un moment où à un autre. Ça ne veut
pas dire qu'il n'y a aucun problème avec systemd, ça veut dire qu'ils ne
sont pas assez importants pour remonter. Et c'est vraiment loin d'être
la guerre que tu me décris.

Au boulot, le deuxième plus gros problème (après le réseau), c'est
l'obsolescence. Et encore, maintenant que tout est virtualisé, nous
n'avons plus le risque qu'il y avait il y a dix ans de devoir faire les
puces si certaines machines tombaient.

Au boulot, l'un des très gros sujet vient des interfaces entre les
systèmes. Ça, c'est problématique, ça pose plein de soucis de fiabilité
de sécurité, de plein de trucs.

Au boulot, un autre sujet sensible vient à la fois de la sensibilité des
informations pour savoir quelle sécurité appliquer dessus ainsi que la
loi RGPD. Et ça c'est très compliqué car c'est autant décisionnel que
légal que technique.

Le problème d'Oracle qui se met à faire payer java, par exemple, c'est
un vrai sujet parce que ça oblige à savoir où se trouvent les jdk sur
tous les serveurs. Le sujet de dégager les Windows 2003 qui continuent à
trainer c'est un vrai sujet. Le sujet des Red Hat 2 qui continuent à
trainer c'est un vrai sujet. Le sujet des applications mal codées qui
coûtent une fortune en maintenance, c'est un vrai sujet.

Mais le sujet de systemd, au boulot : tout le monde s'en bat les flanc.
Que ce soit pour des sauvegardes. Que ce soit pour des applications sur
le DRP, pour des applications sur le cloud, pour des applications sur
dans les centres de services. Pour des petites applications ou des gros
ERP. Pas une fois, sur tous les problèmes que j'ai pu entendre, pas une
fois quelqu'un m'a dit que c'était l'ordonnancement qui n'était pas
maîtrisé et qu'on ne pouvait pas choisir l'ordre de démarrage. Et je
vais te dire que des sujets j'en ai vu passer.

--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

Vous avez filtré cet utilisateur ! Consultez son message

Le 06-06-2020, JKB a écrit :

Le 06 Jun 2020 10:41:26 GMT,
Stéphane CARPENTIER écrivait :
Ç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 :
https://github.com/systemd/systemd/issues
1224 open, 5016 closed.

Là, tu vas dans mon sens. D'abord, c'est pas une liste de bugs, c'est
une liste de tâches. Il y a un bug reconnu comme tel. Il y a des demandes
d'évolutions. Il y a des gens un peu paumés (ce que je comprends mon
sens n'est pas de dire que systemd est d'une simplicité enfantine).
Sur la première page, il y a 25 demandes. Dont 9 demandes d'évolutions.
Il y a un bug recensé comme tel. Il y a deux demandes d'attentes
d'explications utilisateurs. En gros, sur une application stable avec un
nombre conséquent d'utilisateurs, tu peux t'attendre à 1 bug pour 10
demandes de support. Pour ce que j'en vois on en est très loin (si je
regarde la seconde page, je ne vois qu'un bug et qu'une régression).
Les applications moisies que j'ai pu voir, je t'assure que c'est
vraiment pas le même ratio.
Donc, oui, vu la cabale sur systemd, s'il y avait une foule
d'utilisateur hurlante, elle m'aurait été pointée.

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 premier qui demande comment faire pour que son laptop puisse se
mettre en veille s'il est débranché mais pas s'il est branché et que ça
doit aussi dépendre de s'il est connecté à un moniteur partagé avec un
autre ordinateur n'est quand même pas un truc banal.

(le coup des baux DHCP est amusant, enfin peut-être, faut
juste ne pas être concerné !).

Ce qui est important, c'est pas qu'il y ait des anomalies, c'est que ce
soit vitre traité. Et là, c'est traité en une dizaine de jours, c'est
pas mal.

Ça aussi, c'est éloquent :
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dist=unstable

Oui, ben qu'une testing ne soit pas stable, c'est prévu. C'est pour ça
que ça s'appelle testing. Pour moi, quand il ne trouve pas un fichier de
conf, c'est debian qui intègre mal le package : c'est pas de la faute de
systemd.

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.

Et bien c'est super alors.

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).

Tu veux dire que si le F5 c'est un bordel immonde que personne ne
maîtrise c'est à cause de systemd ? Tu veux dire que sur mon poste du
boulot, lorsque je vais sur une application Extranet, si ça rame en
traversant 3 routeurs, 5 firewall et 2 F5 c'est à cause de systemd ? On
a des problèmes de réseau super compliqués indémerdable. Je n'ai jamais
entendu de critique de systemd comme source. Le réseau du boulot est
tellement pourri que pour aller sur certaines applications sur
l'Extranet il vaut mieux utiliser son ordinateur personnel.
Alors, oui, je sais, l'architecture c'est super important. Je m'engueule
assez souvent avec des architectes et des gens de la sécurité pour savoir
quelles sont les contraintes. Et c'est marrant, mais systemd, c'est
jamais, mais alors jamais, dans la liste des sujets. C'est chez moi que
j'ai découvert ça. Quand les architectes me proposent une solution,
plein de trucs peuvent être mentionnés, mais jamais systemd ne rentre en
ligne de compte : ils s'en cognent.

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.

Je ne te parle pas de juste des cas particuliers qui tombent en marche
par chance. Je te dis que pour ce que je vois, systemd ne pose pas de
problème. Je travaille à la DSI d'une grosse entreprise. Je sais ce qui
pose problème sur nos applications. Parce que les gros problèmes j'en
entend parler. Si systemd faisait partie du TOP 100 des sujets, j'en
aurais forcément entendu parler à un moment où à un autre. Ça ne veut
pas dire qu'il n'y a aucun problème avec systemd, ça veut dire qu'ils ne
sont pas assez importants pour remonter. Et c'est vraiment loin d'être
la guerre que tu me décris.
Au boulot, le deuxième plus gros problème (après le réseau), c'est
l'obsolescence. Et encore, maintenant que tout est virtualisé, nous
n'avons plus le risque qu'il y avait il y a dix ans de devoir faire les
puces si certaines machines tombaient.
Au boulot, l'un des très gros sujet vient des interfaces entre les
systèmes. Ça, c'est problématique, ça pose plein de soucis de fiabilité
de sécurité, de plein de trucs.
Au boulot, un autre sujet sensible vient à la fois de la sensibilité des
informations pour savoir quelle sécurité appliquer dessus ainsi que la
loi RGPD. Et ça c'est très compliqué car c'est autant décisionnel que
légal que technique.
Le problème d'Oracle qui se met à faire payer java, par exemple, c'est
un vrai sujet parce que ça oblige à savoir où se trouvent les jdk sur
tous les serveurs. Le sujet de dégager les Windows 2003 qui continuent à
trainer c'est un vrai sujet. Le sujet des Red Hat 2 qui continuent à
trainer c'est un vrai sujet. Le sujet des applications mal codées qui
coûtent une fortune en maintenance, c'est un vrai sujet.
Mais le sujet de systemd, au boulot : tout le monde s'en bat les flanc.
Que ce soit pour des sauvegardes. Que ce soit pour des applications sur
le DRP, pour des applications sur le cloud, pour des applications sur
dans les centres de services. Pour des petites applications ou des gros
ERP. Pas une fois, sur tous les problèmes que j'ai pu entendre, pas une
fois quelqu'un m'a dit que c'était l'ordonnancement qui n'était pas
maîtrisé et qu'on ne pouvait pas choisir l'ordre de démarrage. Et je
vais te dire que des sujets j'en ai vu passer.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

Stéphane CARPENTIER

06/06/2020 à 17:07

Le 06-06-2020, Yliur a écrit :

brut sans même regarder ce qu'il y a dedans c'est de la mauvaise foi
quand même...

Oui, mais il a le droit ici. C'est le forum de la mauvaise foi. Ça ne
peut pas lui être reproché.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

JKB

06/06/2020 à 17:13

Le Sat, 6 Jun 2020 13:58:28 -0000 (UTC),
Yliur écrivait :

Le Sat, 06 Jun 2020 12:34:07 +0000, JKB a écrit :
Pour fixer les idées :
https://github.com/systemd/systemd/issues 1224 open, 5016 closed.

Sauf que dans la liste il y a des choses qui vont du bug à la demande
d'amélioration, en passant par des questions limite forum (du type "je ne
vois pas comment faire ça", sans que ça ait forcément (encore) été trié
comme demande d'amélioration)
Si on ne considère que l'étiquette "bug", on a ça : 89 open, 829 closed.
Il se peut qu'en réalité ce soit un peu plus, mais prendre le chiffre
brut sans même regarder ce qu'il y a dedans c'est de la mauvaise foi
quand même...

Même s'il n'y en a _que_ 1000, ça fait beaucoup pour un daemon qui
devrait être trivial et entièrement prouvé (parce que c'est tout de
même sur lui que repose la stabilité du système).

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 !

Chez moi aussi, sauf que top dit ça :
VIRT : 175288
RES : 5292
%MEM : 0,0
Donc si je comprends bien, 170Mo de mémoire virtuelle mais seulement 5Mo
de mémoire réservée. Ce qui peut aussi bien signifier que plein de code
est associé à la mémoire virtuelle du processus mais que ce n'est pas
forcément chargé en mémoire.

Ça veut surtout dire virtuelle et résidente à l'instant /t/.
Il y a 170 Mo de mémoire réservée quelque part (allocations mémoire,
bibliothèques partagées le cas échéant) qui consomment des
ressources.

Par "verrouillé en mémoire", tu veux dire que le code devrait rester en
mémoire en permanence ?

Oui. mlock est fait pour cela. Il y a des cas où systemd file dans
le swap et le résultat est... intéressant !

Auquel cas j'imagine que c'est moins intéressant
s'il y en a beaucoup. Mais pourquoi le fait qu'un bout de code du système
d'initialisation qui ne sert jamais reste en mémoire est plus pertinent
que pour n'importe quel processus ?

Parce que init doit récupérer tout un tas de choses dont les codes
de retour de tous les processus sous peine d'avoir des zombies. Pour
mémoire, un zombie, c'est un processus dont le père ou init n'est
pas allé à l'enterrement. Si à chaque fois qu'un processus lancé par
init s'achève, que init est dans le swap et que ton système va
chercher les pages dans le swap pour simplement lire la valeur de
retour du fils, je pense que tu vas assez rapidement t'énerver. Et
c'est assez vite le cas sous Linux depuis quelques noyaux, la valeur
de vm.swapiness ne servant quasiment plus à rien.
Le noyau, dans sa majorité, doit rester en mémoire (le noyau Linux
sauf si cela a changé depuis que j'ai arrêté de tripatouillé à
l'intérieur, est totalement verrouillé en mémoire). Pour des raisons
de performances, il est bon que le PID 1 y reste aussi.

Depuis le 13 mai, on se demande ce qu'il a fait en consommant
1h04 de temps CPU.
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).

Pareil ici, mais ça représente environ 2 minutes par jour.
Ta comparaison avec NetBSD, c'est à périmètre équivalent ? Par exemple
systemd gère des journaux, le temps de traitement lui est sans doute
attribué.

Tiens parlons-en. Le fait que les journaux soient sous forme
binaire est un autre truc inacceptable. Malgré le fait que NetBSD
écrit des lignes et des lignes en raison d'un client NFS de FreeBSD
problématique (lockd), le temps CPU utilisé par syslog n'arrive pas
à la cheville de celui utilisé par systemd.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

Le Sat, 6 Jun 2020 13:58:28 -0000 (UTC),
Yliur <yliur@free.fr> écrivait :

Le Sat, 06 Jun 2020 12:34:07 +0000, JKB a écrit :

Pour fixer les idées :

https://github.com/systemd/systemd/issues 1224 open, 5016 closed.

Sauf que dans la liste il y a des choses qui vont du bug à la demande
d'amélioration, en passant par des questions limite forum (du type "je ne
vois pas comment faire ça", sans que ça ait forcément (encore) été trié
comme demande d'amélioration)

Si on ne considère que l'étiquette "bug", on a ça : 89 open, 829 closed.

Il se peut qu'en réalité ce soit un peu plus, mais prendre le chiffre
brut sans même regarder ce qu'il y a dedans c'est de la mauvaise foi
quand même...

Même s'il n'y en a _que_ 1000, ça fait beaucoup pour un daemon qui
devrait être trivial et entièrement prouvé (parce que c'est tout de
même sur lui que repose la stabilité du système).

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 !

Chez moi aussi, sauf que top dit ça :
VIRT : 175288
RES : 5292
%MEM : 0,0

Donc si je comprends bien, 170Mo de mémoire virtuelle mais seulement 5Mo
de mémoire réservée. Ce qui peut aussi bien signifier que plein de code
est associé à la mémoire virtuelle du processus mais que ce n'est pas
forcément chargé en mémoire.

Ça veut surtout dire virtuelle et résidente à l'instant /t/.
Il y a 170 Mo de mémoire réservée quelque part (allocations mémoire,
bibliothèques partagées le cas échéant) qui consomment des
ressources.

Par "verrouillé en mémoire", tu veux dire que le code devrait rester en
mémoire en permanence ?

Oui. mlock est fait pour cela. Il y a des cas où systemd file dans
le swap et le résultat est... intéressant !

Auquel cas j'imagine que c'est moins intéressant
s'il y en a beaucoup. Mais pourquoi le fait qu'un bout de code du système
d'initialisation qui ne sert jamais reste en mémoire est plus pertinent
que pour n'importe quel processus ?

Parce que init doit récupérer tout un tas de choses dont les codes
de retour de tous les processus sous peine d'avoir des zombies. Pour
mémoire, un zombie, c'est un processus dont le père ou init n'est
pas allé à l'enterrement. Si à chaque fois qu'un processus lancé par
init s'achève, que init est dans le swap et que ton système va
chercher les pages dans le swap pour simplement lire la valeur de
retour du fils, je pense que tu vas assez rapidement t'énerver. Et
c'est assez vite le cas sous Linux depuis quelques noyaux, la valeur
de vm.swapiness ne servant quasiment plus à rien.

Le noyau, dans sa majorité, doit rester en mémoire (le noyau Linux
sauf si cela a changé depuis que j'ai arrêté de tripatouillé à
l'intérieur, est totalement verrouillé en mémoire). Pour des raisons
de performances, il est bon que le PID 1 y reste aussi.

Depuis le 13 mai, on se demande ce qu'il a fait en consommant
1h04 de temps CPU.

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).

Pareil ici, mais ça représente environ 2 minutes par jour.

Ta comparaison avec NetBSD, c'est à périmètre équivalent ? Par exemple
systemd gère des journaux, le temps de traitement lui est sans doute
attribué.

Tiens parlons-en. Le fait que les journaux soient sous forme
binaire est un autre truc inacceptable. Malgré le fait que NetBSD
écrit des lignes et des lignes en raison d'un client NFS de FreeBSD
problématique (lockd), le temps CPU utilisé par syslog n'arrive pas
à la cheville de celui utilisé par systemd.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

Vous avez filtré cet utilisateur ! Consultez son message

Le Sat, 6 Jun 2020 13:58:28 -0000 (UTC),
Yliur écrivait :

Le Sat, 06 Jun 2020 12:34:07 +0000, JKB a écrit :
Pour fixer les idées :
https://github.com/systemd/systemd/issues 1224 open, 5016 closed.

Sauf que dans la liste il y a des choses qui vont du bug à la demande
d'amélioration, en passant par des questions limite forum (du type "je ne
vois pas comment faire ça", sans que ça ait forcément (encore) été trié
comme demande d'amélioration)
Si on ne considère que l'étiquette "bug", on a ça : 89 open, 829 closed.
Il se peut qu'en réalité ce soit un peu plus, mais prendre le chiffre
brut sans même regarder ce qu'il y a dedans c'est de la mauvaise foi
quand même...

Même s'il n'y en a _que_ 1000, ça fait beaucoup pour un daemon qui
devrait être trivial et entièrement prouvé (parce que c'est tout de
même sur lui que repose la stabilité du système).

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 !

Chez moi aussi, sauf que top dit ça :
VIRT : 175288
RES : 5292
%MEM : 0,0
Donc si je comprends bien, 170Mo de mémoire virtuelle mais seulement 5Mo
de mémoire réservée. Ce qui peut aussi bien signifier que plein de code
est associé à la mémoire virtuelle du processus mais que ce n'est pas
forcément chargé en mémoire.

Ça veut surtout dire virtuelle et résidente à l'instant /t/.
Il y a 170 Mo de mémoire réservée quelque part (allocations mémoire,
bibliothèques partagées le cas échéant) qui consomment des
ressources.

Par "verrouillé en mémoire", tu veux dire que le code devrait rester en
mémoire en permanence ?

Oui. mlock est fait pour cela. Il y a des cas où systemd file dans
le swap et le résultat est... intéressant !

Auquel cas j'imagine que c'est moins intéressant
s'il y en a beaucoup. Mais pourquoi le fait qu'un bout de code du système
d'initialisation qui ne sert jamais reste en mémoire est plus pertinent
que pour n'importe quel processus ?

Parce que init doit récupérer tout un tas de choses dont les codes
de retour de tous les processus sous peine d'avoir des zombies. Pour
mémoire, un zombie, c'est un processus dont le père ou init n'est
pas allé à l'enterrement. Si à chaque fois qu'un processus lancé par
init s'achève, que init est dans le swap et que ton système va
chercher les pages dans le swap pour simplement lire la valeur de
retour du fils, je pense que tu vas assez rapidement t'énerver. Et
c'est assez vite le cas sous Linux depuis quelques noyaux, la valeur
de vm.swapiness ne servant quasiment plus à rien.
Le noyau, dans sa majorité, doit rester en mémoire (le noyau Linux
sauf si cela a changé depuis que j'ai arrêté de tripatouillé à
l'intérieur, est totalement verrouillé en mémoire). Pour des raisons
de performances, il est bon que le PID 1 y reste aussi.

Depuis le 13 mai, on se demande ce qu'il a fait en consommant
1h04 de temps CPU.
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).

Pareil ici, mais ça représente environ 2 minutes par jour.
Ta comparaison avec NetBSD, c'est à périmètre équivalent ? Par exemple
systemd gère des journaux, le temps de traitement lui est sans doute
attribué.

Tiens parlons-en. Le fait que les journaux soient sous forme
binaire est un autre truc inacceptable. Malgré le fait que NetBSD
écrit des lignes et des lignes en raison d'un client NFS de FreeBSD
problématique (lockd), le temps CPU utilisé par syslog n'arrive pas
à la cheville de celui utilisé par systemd.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

Stéphane CARPENTIER

06/06/2020 à 17:35

Le 06-06-2020, JKB a écrit :

Le Sat, 6 Jun 2020 13:58:28 -0000 (UTC),
Même s'il n'y en a _que_ 1000, ça fait beaucoup pour un daemon qui
devrait être trivial et entièrement prouvé (parce que c'est tout de
même sur lui que repose la stabilité du système).

Pas forcément, ça dépend autant de leur sévérité et de leur temps de
traitement. Si tu fais du déploiement par lot, oui, il faut beaucoup
tester avant chaque livraison. Mais si tu fais du développement continu,
tu ne t'inquiètes pas trop des problèmes mineurs car c'est facile de
revenir en arrière.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

JKB

06/06/2020 à 17:38

Le 06 Jun 2020 14:58:49 GMT,
Stéphane CARPENTIER écrivait :

Le 06-06-2020, JKB a écrit :
Ça aussi, c'est éloquent :
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dist=unstable

Oui, ben qu'une testing ne soit pas stable, c'est prévu. C'est pour ça
que ça s'appelle testing. Pour moi, quand il ne trouve pas un fichier de
conf, c'est debian qui intègre mal le package : c'est pas de la faute de
systemd.

La liste des bugs est la liste historique du paquet quelle que soit
la distribution. Il n'y a pas de notion de unstable dans les bugs
retournés.

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).

Tu veux dire que si le F5 c'est un bordel immonde que personne ne
maîtrise c'est à cause de systemd ? Tu veux dire que sur mon poste du
boulot, lorsque je vais sur une application Extranet, si ça rame en
traversant 3 routeurs, 5 firewall et 2 F5 c'est à cause de systemd ? On
a des problèmes de réseau super compliqués indémerdable. Je n'ai jamais
entendu de critique de systemd comme source. Le réseau du boulot est
tellement pourri que pour aller sur certaines applications sur
l'Extranet il vaut mieux utiliser son ordinateur personnel.

Le problème de systemd, c'est qu'il est foutu de ne pas démarrer
correctement les interfaces réseau dans l'ordre, voire de les
renommer. Les résultats peuvent être... intéressants. Ça va du
serveur injoignable à des services qui plantent au démarrage (style
Apache qui doit écouter explicitement sur une interface VPN que
systemd n'a pas réussi à monter correctement). Je ne te parle même
pas des firewalls en cas d'interfaces réseau renommées ! Je n'ai pas vu de
problèems de routage associé à systemd parce que lorsqu'il arrive à
traiter une interface, elle est traitée jusqu'au bout. Le problème de
systemd, c'est dans les détails. After ou Requires fonctionnent
moyennement parce certains daemons commencent par se forker
eux-mêmes (même deux fois). Il y avait une version d'OpenVPN qui
faisait cela et renvoyait un beau 0 à systemd, lequel considérait
que les interfaces tap était existantes et continuait. Manque de
bol, aléatoirement, elles n'étaient pas encore montées lorsque les
services suivants déboulaient pour les utiliser ! Je ne sais plus
comment j'ai corrigé le problème, mais j'ai passé du temps dessus !
Je me demande s'il n'y a pas un script quelque part qui va regarder
dans les interfaces réseau si les tap0/1/2 sont montées et qui est
un prérequis d'apache. Simple comme solution !
Avec SysV ou rcorder, la solution est particulièrement triviale.

Alors, oui, je sais, l'architecture c'est super important. Je m'engueule
assez souvent avec des architectes et des gens de la sécurité pour savoir
quelles sont les contraintes. Et c'est marrant, mais systemd, c'est
jamais, mais alors jamais, dans la liste des sujets. C'est chez moi que
j'ai découvert ça. Quand les architectes me proposent une solution,
plein de trucs peuvent être mentionnés, mais jamais systemd ne rentre en
ligne de compte : ils s'en cognent.

Quand on est intoxiqué, on n'arrive même pas à imaginer qu'il existe
autre chose. C'est un syndrome assez classique, surtout dans
l'informatique où lorsqu'on a un marteau, tous les problèmes
ressemblent à des clous.

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.

Je ne te parle pas de juste des cas particuliers qui tombent en marche
par chance. Je te dis que pour ce que je vois, systemd ne pose pas de
problème. Je travaille à la DSI d'une grosse entreprise. Je sais ce qui
pose problème sur nos applications. Parce que les gros problèmes j'en
entend parler. Si systemd faisait partie du TOP 100 des sujets, j'en
aurais forcément entendu parler à un moment où à un autre. Ça ne veut
pas dire qu'il n'y a aucun problème avec systemd, ça veut dire qu'ils ne
sont pas assez importants pour remonter. Et c'est vraiment loin d'être
la guerre que tu me décris.
Au boulot, le deuxième plus gros problème (après le réseau), c'est
l'obsolescence. Et encore, maintenant que tout est virtualisé, nous
n'avons plus le risque qu'il y avait il y a dix ans de devoir faire les
puces si certaines machines tombaient.
Au boulot, l'un des très gros sujet vient des interfaces entre les
systèmes. Ça, c'est problématique, ça pose plein de soucis de fiabilité
de sécurité, de plein de trucs.
Au boulot, un autre sujet sensible vient à la fois de la sensibilité des
informations pour savoir quelle sécurité appliquer dessus ainsi que la
loi RGPD. Et ça c'est très compliqué car c'est autant décisionnel que
légal que technique.

À ton boulot, tu as la chance d'être devant une machine pour faire
de la maintenance. Dans le mien, la machine est potentiellement à
1000 km sans possibilité d'intervenir dessus. Dans mon boulot, je
n'ai pas forcément un serveur de test dans la même configuration
sous la main pour tester une migration. La migration se fait à chaud
chez le client sur ses heures de boulot. Ça _doit_ marcher. Et
lorsque systemd se met à foutre le bordel parce qu'il a décidé de
fonctionner différemment d'une version à l'autre, j'aimerais bien
avoir les devs du bouzin sous les pattes pour leur dire ma façon de
penser.
Dans une grosse boîte, ce genre de problème est limité parce que
l'infrastructure est beaucoup plus importante. Tu ne vas pas avoir
le même serveur qui fait routeur/passerelle/proxy web/proxy
SIP/serveur NFS/Samba/VPN/Apache et j'en passe. Sur les
configurations standard, ça passe à peu près. C'est sur les
configurations tordues que ça merdoie.

Le problème d'Oracle qui se met à faire payer java, par exemple, c'est
un vrai sujet parce que ça oblige à savoir où se trouvent les jdk sur
tous les serveurs.

Oracle qui fait payer Java, ça me mettrait plutôt en joie.

Le sujet de dégager les Windows 2003 qui continuent à
trainer c'est un vrai sujet. Le sujet des Red Hat 2 qui continuent à
trainer c'est un vrai sujet. Le sujet des applications mal codées qui
coûtent une fortune en maintenance, c'est un vrai sujet.
Mais le sujet de systemd, au boulot : tout le monde s'en bat les flanc.

Tout le monde s'en bat les flancs jusqu'au jour où vous aurez une
belle merde que personne n'avait vu venir parce que tout le monde
s'en battait les flancs et que, jusqu'ici, tout fonctionnait bien.
J'ai un client qui a fait faillite à cause, entre autres,
d'un problème comme ça.

Que ce soit pour des sauvegardes. Que ce soit pour des applications sur
le DRP, pour des applications sur le cloud, pour des applications sur
dans les centres de services. Pour des petites applications ou des gros
ERP. Pas une fois, sur tous les problèmes que j'ai pu entendre, pas une
fois quelqu'un m'a dit que c'était l'ordonnancement qui n'était pas
maîtrisé et qu'on ne pouvait pas choisir l'ordre de démarrage. Et je
vais te dire que des sujets j'en ai vu passer.

Ce que tu m'écris est ridicule. Quand tu es devant une machine, tu
te contrefiches de savoir si le démarrage s'est passé correctement
jusqu'au bout. Si un daemon ne tourne pas, tu le lances à la main.
Lorsque tu es devant une machine pour la redémarrer
et que systemd décide de partir en attente infinie, tu as le bouton
reset. Ça n'a strictement rien à voir avec la capacité de systemd à
lancer une application à la demande une fois que tout est démarré.
J'ai un souvenir ému d'un tomcat qui refusait de partir sous
systemd. Solution des devs de systemd : utiliser un script dans cron pour
vérifier qu'il est lancé cinq minutes après le démarrage !...
Sérieux ?
Maintenant, lorsque ça merde pour une raison indéfinie et que tu es
contraint de mettre les mains dans le cambouis, ça coûte nettement
plus cher de remettre d'équerre un système utilisant systemd qu'un
système utilisant SysV ou rcorder. Pourquoi ? Parce que le temps,
c'est de l'argent et que les solutions aux problèmes systemd
oscillent entre les problèmes de lutins et de chapelier fou. Sur le
papier, c'est simple. Dans les faits, ça peut être extrêmement tordu
parce que systemd fait des hypothèses fortes sur le fonctionnement
des programmes qu'il lance.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

Le 06 Jun 2020 14:58:49 GMT,
Stéphane CARPENTIER <sc@fiat-linux.fr> écrivait :

Le 06-06-2020, JKB <jkb@koenigsberg.invalid> a écrit :

Ça aussi, c'est éloquent :
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dist=unstable

Oui, ben qu'une testing ne soit pas stable, c'est prévu. C'est pour ça
que ça s'appelle testing. Pour moi, quand il ne trouve pas un fichier de
conf, c'est debian qui intègre mal le package : c'est pas de la faute de
systemd.

La liste des bugs est la liste historique du paquet quelle que soit
la distribution. Il n'y a pas de notion de unstable dans les bugs
retournés.

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).

Tu veux dire que si le F5 c'est un bordel immonde que personne ne
maîtrise c'est à cause de systemd ? Tu veux dire que sur mon poste du
boulot, lorsque je vais sur une application Extranet, si ça rame en
traversant 3 routeurs, 5 firewall et 2 F5 c'est à cause de systemd ? On
a des problèmes de réseau super compliqués indémerdable. Je n'ai jamais
entendu de critique de systemd comme source. Le réseau du boulot est
tellement pourri que pour aller sur certaines applications sur
l'Extranet il vaut mieux utiliser son ordinateur personnel.

Le problème de systemd, c'est qu'il est foutu de ne pas démarrer
correctement les interfaces réseau dans l'ordre, voire de les
renommer. Les résultats peuvent être... intéressants. Ça va du
serveur injoignable à des services qui plantent au démarrage (style
Apache qui doit écouter explicitement sur une interface VPN que
systemd n'a pas réussi à monter correctement). Je ne te parle même
pas des firewalls en cas d'interfaces réseau renommées ! Je n'ai pas vu de
problèems de routage associé à systemd parce que lorsqu'il arrive à
traiter une interface, elle est traitée jusqu'au bout. Le problème de
systemd, c'est dans les détails. After ou Requires fonctionnent
moyennement parce certains daemons commencent par se forker
eux-mêmes (même deux fois). Il y avait une version d'OpenVPN qui
faisait cela et renvoyait un beau 0 à systemd, lequel considérait
que les interfaces tap était existantes et continuait. Manque de
bol, aléatoirement, elles n'étaient pas encore montées lorsque les
services suivants déboulaient pour les utiliser ! Je ne sais plus
comment j'ai corrigé le problème, mais j'ai passé du temps dessus !
Je me demande s'il n'y a pas un script quelque part qui va regarder
dans les interfaces réseau si les tap0/1/2 sont montées et qui est
un prérequis d'apache. Simple comme solution !

Avec SysV ou rcorder, la solution est particulièrement triviale.

Alors, oui, je sais, l'architecture c'est super important. Je m'engueule
assez souvent avec des architectes et des gens de la sécurité pour savoir
quelles sont les contraintes. Et c'est marrant, mais systemd, c'est
jamais, mais alors jamais, dans la liste des sujets. C'est chez moi que
j'ai découvert ça. Quand les architectes me proposent une solution,
plein de trucs peuvent être mentionnés, mais jamais systemd ne rentre en
ligne de compte : ils s'en cognent.

Quand on est intoxiqué, on n'arrive même pas à imaginer qu'il existe
autre chose. C'est un syndrome assez classique, surtout dans
l'informatique où lorsqu'on a un marteau, tous les problèmes
ressemblent à des clous.

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.

Je ne te parle pas de juste des cas particuliers qui tombent en marche
par chance. Je te dis que pour ce que je vois, systemd ne pose pas de
problème. Je travaille à la DSI d'une grosse entreprise. Je sais ce qui
pose problème sur nos applications. Parce que les gros problèmes j'en
entend parler. Si systemd faisait partie du TOP 100 des sujets, j'en
aurais forcément entendu parler à un moment où à un autre. Ça ne veut
pas dire qu'il n'y a aucun problème avec systemd, ça veut dire qu'ils ne
sont pas assez importants pour remonter. Et c'est vraiment loin d'être
la guerre que tu me décris.

Au boulot, le deuxième plus gros problème (après le réseau), c'est
l'obsolescence. Et encore, maintenant que tout est virtualisé, nous
n'avons plus le risque qu'il y avait il y a dix ans de devoir faire les
puces si certaines machines tombaient.

Au boulot, l'un des très gros sujet vient des interfaces entre les
systèmes. Ça, c'est problématique, ça pose plein de soucis de fiabilité
de sécurité, de plein de trucs.

Au boulot, un autre sujet sensible vient à la fois de la sensibilité des
informations pour savoir quelle sécurité appliquer dessus ainsi que la
loi RGPD. Et ça c'est très compliqué car c'est autant décisionnel que
légal que technique.

À ton boulot, tu as la chance d'être devant une machine pour faire
de la maintenance. Dans le mien, la machine est potentiellement à
1000 km sans possibilité d'intervenir dessus. Dans mon boulot, je
n'ai pas forcément un serveur de test dans la même configuration
sous la main pour tester une migration. La migration se fait à chaud
chez le client sur ses heures de boulot. Ça _doit_ marcher. Et
lorsque systemd se met à foutre le bordel parce qu'il a décidé de
fonctionner différemment d'une version à l'autre, j'aimerais bien
avoir les devs du bouzin sous les pattes pour leur dire ma façon de
penser.

Dans une grosse boîte, ce genre de problème est limité parce que
l'infrastructure est beaucoup plus importante. Tu ne vas pas avoir
le même serveur qui fait routeur/passerelle/proxy web/proxy
SIP/serveur NFS/Samba/VPN/Apache et j'en passe. Sur les
configurations standard, ça passe à peu près. C'est sur les
configurations tordues que ça merdoie.

Le problème d'Oracle qui se met à faire payer java, par exemple, c'est
un vrai sujet parce que ça oblige à savoir où se trouvent les jdk sur
tous les serveurs.

Oracle qui fait payer Java, ça me mettrait plutôt en joie.

Le sujet de dégager les Windows 2003 qui continuent à
trainer c'est un vrai sujet. Le sujet des Red Hat 2 qui continuent à
trainer c'est un vrai sujet. Le sujet des applications mal codées qui
coûtent une fortune en maintenance, c'est un vrai sujet.

Mais le sujet de systemd, au boulot : tout le monde s'en bat les flanc.

Tout le monde s'en bat les flancs jusqu'au jour où vous aurez une
belle merde que personne n'avait vu venir parce que tout le monde
s'en battait les flancs et que, jusqu'ici, tout fonctionnait bien.
J'ai un client qui a fait faillite à cause, entre autres,
d'un problème comme ça.

Que ce soit pour des sauvegardes. Que ce soit pour des applications sur
le DRP, pour des applications sur le cloud, pour des applications sur
dans les centres de services. Pour des petites applications ou des gros
ERP. Pas une fois, sur tous les problèmes que j'ai pu entendre, pas une
fois quelqu'un m'a dit que c'était l'ordonnancement qui n'était pas
maîtrisé et qu'on ne pouvait pas choisir l'ordre de démarrage. Et je
vais te dire que des sujets j'en ai vu passer.

Ce que tu m'écris est ridicule. Quand tu es devant une machine, tu
te contrefiches de savoir si le démarrage s'est passé correctement
jusqu'au bout. Si un daemon ne tourne pas, tu le lances à la main.
Lorsque tu es devant une machine pour la redémarrer
et que systemd décide de partir en attente infinie, tu as le bouton
reset. Ça n'a strictement rien à voir avec la capacité de systemd à
lancer une application à la demande une fois que tout est démarré.
J'ai un souvenir ému d'un tomcat qui refusait de partir sous
systemd. Solution des devs de systemd : utiliser un script dans cron pour
vérifier qu'il est lancé cinq minutes après le démarrage !...
Sérieux ?

Maintenant, lorsque ça merde pour une raison indéfinie et que tu es
contraint de mettre les mains dans le cambouis, ça coûte nettement
plus cher de remettre d'équerre un système utilisant systemd qu'un
système utilisant SysV ou rcorder. Pourquoi ? Parce que le temps,
c'est de l'argent et que les solutions aux problèmes systemd
oscillent entre les problèmes de lutins et de chapelier fou. Sur le
papier, c'est simple. Dans les faits, ça peut être extrêmement tordu
parce que systemd fait des hypothèses fortes sur le fonctionnement
des programmes qu'il lance.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

Vous avez filtré cet utilisateur ! Consultez son message

Le 06 Jun 2020 14:58:49 GMT,
Stéphane CARPENTIER écrivait :

Le 06-06-2020, JKB a écrit :
Ça aussi, c'est éloquent :
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dist=unstable

Oui, ben qu'une testing ne soit pas stable, c'est prévu. C'est pour ça
que ça s'appelle testing. Pour moi, quand il ne trouve pas un fichier de
conf, c'est debian qui intègre mal le package : c'est pas de la faute de
systemd.

La liste des bugs est la liste historique du paquet quelle que soit
la distribution. Il n'y a pas de notion de unstable dans les bugs
retournés.

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).

Tu veux dire que si le F5 c'est un bordel immonde que personne ne
maîtrise c'est à cause de systemd ? Tu veux dire que sur mon poste du
boulot, lorsque je vais sur une application Extranet, si ça rame en
traversant 3 routeurs, 5 firewall et 2 F5 c'est à cause de systemd ? On
a des problèmes de réseau super compliqués indémerdable. Je n'ai jamais
entendu de critique de systemd comme source. Le réseau du boulot est
tellement pourri que pour aller sur certaines applications sur
l'Extranet il vaut mieux utiliser son ordinateur personnel.

Le problème de systemd, c'est qu'il est foutu de ne pas démarrer
correctement les interfaces réseau dans l'ordre, voire de les
renommer. Les résultats peuvent être... intéressants. Ça va du
serveur injoignable à des services qui plantent au démarrage (style
Apache qui doit écouter explicitement sur une interface VPN que
systemd n'a pas réussi à monter correctement). Je ne te parle même
pas des firewalls en cas d'interfaces réseau renommées ! Je n'ai pas vu de
problèems de routage associé à systemd parce que lorsqu'il arrive à
traiter une interface, elle est traitée jusqu'au bout. Le problème de
systemd, c'est dans les détails. After ou Requires fonctionnent
moyennement parce certains daemons commencent par se forker
eux-mêmes (même deux fois). Il y avait une version d'OpenVPN qui
faisait cela et renvoyait un beau 0 à systemd, lequel considérait
que les interfaces tap était existantes et continuait. Manque de
bol, aléatoirement, elles n'étaient pas encore montées lorsque les
services suivants déboulaient pour les utiliser ! Je ne sais plus
comment j'ai corrigé le problème, mais j'ai passé du temps dessus !
Je me demande s'il n'y a pas un script quelque part qui va regarder
dans les interfaces réseau si les tap0/1/2 sont montées et qui est
un prérequis d'apache. Simple comme solution !
Avec SysV ou rcorder, la solution est particulièrement triviale.

Alors, oui, je sais, l'architecture c'est super important. Je m'engueule
assez souvent avec des architectes et des gens de la sécurité pour savoir
quelles sont les contraintes. Et c'est marrant, mais systemd, c'est
jamais, mais alors jamais, dans la liste des sujets. C'est chez moi que
j'ai découvert ça. Quand les architectes me proposent une solution,
plein de trucs peuvent être mentionnés, mais jamais systemd ne rentre en
ligne de compte : ils s'en cognent.

Quand on est intoxiqué, on n'arrive même pas à imaginer qu'il existe
autre chose. C'est un syndrome assez classique, surtout dans
l'informatique où lorsqu'on a un marteau, tous les problèmes
ressemblent à des clous.

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.

Je ne te parle pas de juste des cas particuliers qui tombent en marche
par chance. Je te dis que pour ce que je vois, systemd ne pose pas de
problème. Je travaille à la DSI d'une grosse entreprise. Je sais ce qui
pose problème sur nos applications. Parce que les gros problèmes j'en
entend parler. Si systemd faisait partie du TOP 100 des sujets, j'en
aurais forcément entendu parler à un moment où à un autre. Ça ne veut
pas dire qu'il n'y a aucun problème avec systemd, ça veut dire qu'ils ne
sont pas assez importants pour remonter. Et c'est vraiment loin d'être
la guerre que tu me décris.
Au boulot, le deuxième plus gros problème (après le réseau), c'est
l'obsolescence. Et encore, maintenant que tout est virtualisé, nous
n'avons plus le risque qu'il y avait il y a dix ans de devoir faire les
puces si certaines machines tombaient.
Au boulot, l'un des très gros sujet vient des interfaces entre les
systèmes. Ça, c'est problématique, ça pose plein de soucis de fiabilité
de sécurité, de plein de trucs.
Au boulot, un autre sujet sensible vient à la fois de la sensibilité des
informations pour savoir quelle sécurité appliquer dessus ainsi que la
loi RGPD. Et ça c'est très compliqué car c'est autant décisionnel que
légal que technique.

À ton boulot, tu as la chance d'être devant une machine pour faire
de la maintenance. Dans le mien, la machine est potentiellement à
1000 km sans possibilité d'intervenir dessus. Dans mon boulot, je
n'ai pas forcément un serveur de test dans la même configuration
sous la main pour tester une migration. La migration se fait à chaud
chez le client sur ses heures de boulot. Ça _doit_ marcher. Et
lorsque systemd se met à foutre le bordel parce qu'il a décidé de
fonctionner différemment d'une version à l'autre, j'aimerais bien
avoir les devs du bouzin sous les pattes pour leur dire ma façon de
penser.
Dans une grosse boîte, ce genre de problème est limité parce que
l'infrastructure est beaucoup plus importante. Tu ne vas pas avoir
le même serveur qui fait routeur/passerelle/proxy web/proxy
SIP/serveur NFS/Samba/VPN/Apache et j'en passe. Sur les
configurations standard, ça passe à peu près. C'est sur les
configurations tordues que ça merdoie.

Le problème d'Oracle qui se met à faire payer java, par exemple, c'est
un vrai sujet parce que ça oblige à savoir où se trouvent les jdk sur
tous les serveurs.

Oracle qui fait payer Java, ça me mettrait plutôt en joie.

Le sujet de dégager les Windows 2003 qui continuent à
trainer c'est un vrai sujet. Le sujet des Red Hat 2 qui continuent à
trainer c'est un vrai sujet. Le sujet des applications mal codées qui
coûtent une fortune en maintenance, c'est un vrai sujet.
Mais le sujet de systemd, au boulot : tout le monde s'en bat les flanc.

Tout le monde s'en bat les flancs jusqu'au jour où vous aurez une
belle merde que personne n'avait vu venir parce que tout le monde
s'en battait les flancs et que, jusqu'ici, tout fonctionnait bien.
J'ai un client qui a fait faillite à cause, entre autres,
d'un problème comme ça.

Que ce soit pour des sauvegardes. Que ce soit pour des applications sur
le DRP, pour des applications sur le cloud, pour des applications sur
dans les centres de services. Pour des petites applications ou des gros
ERP. Pas une fois, sur tous les problèmes que j'ai pu entendre, pas une
fois quelqu'un m'a dit que c'était l'ordonnancement qui n'était pas
maîtrisé et qu'on ne pouvait pas choisir l'ordre de démarrage. Et je
vais te dire que des sujets j'en ai vu passer.

Ce que tu m'écris est ridicule. Quand tu es devant une machine, tu
te contrefiches de savoir si le démarrage s'est passé correctement
jusqu'au bout. Si un daemon ne tourne pas, tu le lances à la main.
Lorsque tu es devant une machine pour la redémarrer
et que systemd décide de partir en attente infinie, tu as le bouton
reset. Ça n'a strictement rien à voir avec la capacité de systemd à
lancer une application à la demande une fois que tout est démarré.
J'ai un souvenir ému d'un tomcat qui refusait de partir sous
systemd. Solution des devs de systemd : utiliser un script dans cron pour
vérifier qu'il est lancé cinq minutes après le démarrage !...
Sérieux ?
Maintenant, lorsque ça merde pour une raison indéfinie et que tu es
contraint de mettre les mains dans le cambouis, ça coûte nettement
plus cher de remettre d'équerre un système utilisant systemd qu'un
système utilisant SysV ou rcorder. Pourquoi ? Parce que le temps,
c'est de l'argent et que les solutions aux problèmes systemd
oscillent entre les problèmes de lutins et de chapelier fou. Sur le
papier, c'est simple. Dans les faits, ça peut être extrêmement tordu
parce que systemd fait des hypothèses fortes sur le fonctionnement
des programmes qu'il lance.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

Redhat

10 réponses

Veuillez sélectionner un problème