Le 06-06-2020, Nicolas George <nicolas$george> 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é.

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

> Pour fixer les idées :
> [..] 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 06-06-2020, JKB <jkb> a écrit :
> Le 06 Jun 2020 10:41:26 GMT,
> Stéphane CARPENTIER <sc> écrivait :
> Il y a plein de choses qui peuvent marcher. Ce qui rate peut aussi
> marcher de temps en temps. C'est assez shadokien comme logique.
> Pour fixer les idées :
> [..]
> 1224 open, 5016 closed.

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 :
> [..]

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.

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

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

Le 06-06-2020, Yliur <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é.

Le Sat, 6 Jun 2020 13:58:28 -0000 (UTC),
Yliur <yliur> écrivait :
> Le Sat, 06 Jun 2020 12:34:07 +0000, JKB a écrit :
> 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).

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

> 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

Le 06-06-2020, JKB <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.

Le 06 Jun 2020 14:58:49 GMT,
Stéphane CARPENTIER <sc> écrivait :
> Le 06-06-2020, JKB <jkb> a écrit :
>> Ça aussi, c'est éloquent :
>> [..]
> 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.

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

[..]
> 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