Redhat

Nicolas George

06/06/2020 à 19:32

JKB , dans le message , a
écrit :

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

C'est avéré, JKB ne sait pas comment marche la gestion de la mémoire d'un OS
de moins de trente ans.

Nicolas George

06/06/2020 à 19:40

Stéphane CARPENTIER , dans le message
, a écrit :

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.

La manifestation de ces phénomènes va suivre une gaussienne : certains les
manifesteront beaucoup, certains un tout petit peu, la majorité moyennement.
Mais on entendra surtout ceux qui le manifestent beaucoup.

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.

Ceux qui vont avoir de la dissonance cognitive contre systemd, ce sont
justement ceux qui ont investi beaucoup de temps et d'efforts à faire des
trucs inhabituels et fins avec SysV init, pas juste l'utiliser de manière
standard.

Stéphane CARPENTIER

06/06/2020 à 20:50

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

Le 06 Jun 2020 14:58:49 GMT,
Stéphane CARPENTIER écrivait :
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,

Là, on se répète. Effectivement par design, systemd n'est pas conçu pour
ordonnancer le démarrage. Donc, je ne vais pas dire que j'en suis
surpris.

voire de les renommer.

Oui, il les renomme, mais quand j'ai cherché à comprendre, j'ai vu des
explications qui semblaient prédictibles et effectivement, le nom de mes
interfaces réseau était prévu. Maintenant, sur mon laptop j'ai pas
ouatmillion d'interface réseau. Pour les routeurs/firewall/F5 et tous
les équipements réseau, je ne sais pas s'il y a du systemd dedans, mais
si à chaque démarrage il fallait tout reconfiguré parce que tout avait
été renommé ça se verrait.

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.

À ton boulot, tu as la chance d'être devant une machine pour faire
de la maintenance.

Non, moi je ne fais pas de maintenance. Mais je bosse avec des gens qui
font de la maintenance. Et ils ne sont pas derrière le serveur. Ils
peuvent avoir accès au serveur, mais pour ça il faut qu'ils se
déplacent. Ce qu'ils évitent de faire, surtout pendant le confinement.

Dans le mien, la machine est potentiellement à 1000 km sans
possibilité d'intervenir dessus.

Tu crois que le DRP est dans la même salle que les serveurs qu'il
redonde ? Tu crois que dans une grosse boîte les admins ont leurs
serveurs dédiés à portée de main ?

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.

Nous non plus mais on fait tout pour l'éviter.

La migration se fait à chaud chez le client sur ses heures de
boulot. Ça _doit_ marcher.

Tu crois qu'une grosse boîte perd combien de million par jour quand
Internet tombe ? Il n'y a pas intérêt que ce soit un con qui ait fait
une manip à l'arrache sur un serveur quand tout tombe.

Dans une grosse boîte, ce genre de problème est limité parce que
l'infrastructure est beaucoup plus importante.

Les deux fois où j'ai entendu un mec faire tomber la prod parce qu'il
croyait être en préprod, je t'assure que ça a eu des conséquences. Et
pas que pour lui (c'était pas deux fois le même). Une fois c'était les
DNS qui étaient flingués une fois c'était l'ERP en pleine cloture
comptable.
Je ne sais pas si tu imagines les conséquences d'un plantage d'ERP en
pleine clôture comptable (une destruction de la BDD, il fallait repartir
des sauvegardes) mais je sais que je n'ai pas besoin de t'expliquer les
conséquences d'une suppression des DNS de la boîte.
Dans une grosse boîte, les virements bancaires sont envoyés au dernier
moment. Parce que l'argent est placé avant virement. Et il y a des
grosses pénalités si le virement est en retard. Il n'y a pas intérêt que
le réseau plante au moment du virement : ça coûte très cher.

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.

T'as d'autres problèmes, lorsque t'as plein d'équipements avec des
équipes différentes qui gèrent les équipements, la modification d'un
équipement a souvent des conséquences imprévues et dures à trouver.
Quand c'est la femme de ménage qui débranche un rack pour brancher son
aspirateur, la cause est assez rapide à trouver bien qu'il faille se
déplacer. Mais quand c'est un système de backup qui prend la main toutes
les cinq minutes alors que c'était pas prévu et que les commandes de
haut niveau ne remontent pas les mêmes infos que les commandes de de bas
niveau, je t'assure que c'est dur à déterminer. Et c'était pas lié à
systemd, c'était la mise à jour du backup à partir du système maître qui
n'a pas été faite.

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.

Je ne lis pas l'avenir et je ne peux pas prédire la pérennité de la
boîte. Mais ça m'étonnerait que ce soit une merde sur systemd qui la
fasse couler. Il y a beaucoup d'autres sujet plus inquiétant avant ça.
Il n'y a pas que systemd qui puisse poser des gros problèmes. Et
aujourd'hui, avec le confinement il y a des vraies complexités. Alors un
systemd qui pourrait potentiellement poser problème bien qu'il n'en ait
jamais vraiment posé, ben c'est pas la priorité. La priorité c'est la
vraie vie avec les problèmes actuels à résoudre.
Parce que quand tout le monde est confiné, les accès se font tous depuis
l'extérieur. Les salles de réunion ne sont plus utilisées, donc tout le
monde utilise l'audio et la vidéoconférence. Et là, l'infra elle a
intérêt à tenir.

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.

Pas plus que de sortir que dans une grosse boite chaque reboot est fait
avec un mec au cul de la machine qui va analyser chaque daemon et
cliquer sur reset jusqu'à ce que ça marche. Personne n'a le temps
pour ça. L'écosystème est super complexe et il y a plein de choses
automatisées.

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.

Non seulement il n'y a personne derrière les machines qui sont dans des
salles serveurs ou sur le cloud, mais en plus, il n'y a personne qui
regarde les daemons. Déjà on essaye de se battre avec l'infra pour
savoir avant l'utilisateur final quand un _service_ tombe (ie : pour que
l'application web marche il faut que le serveur de BDD tourne, que le
serveur applicatif tourne et soit connecté à sa BDD et que le réseau
soit OK). Alors pour le suivi des daemons, désolé, mais les outils de
supervisions le permettent mais personne ne les analyse quand ça marche
globalement.
Il y a des sauvegardes, il y a des arrêts et redémarrages automatisés
de serveurs. Pour passer des patchs de sécurité aussi. Et si systemd
plantait tous les serveurs aussi souvent et systématiquement que tu le
dis sur tous nos serveurs, ce serait la guerre tous les jours.

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.

Je ne sais pas ce qui te fais imaginer que les gens sont au cul des
machines. Les serveurs quand ils ne sont pas dans le cloud, ils sont
dans des salles machines dans des racks et virtualisés. Si tu éteints
l'ESX à l'envie parce que t'as un daemon qui freeze une VM tu ne sais
même pas quelles seront les conséquences.

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.

Merci donc de m'avoir confirmé que si systemd c'était l'horreur pour nos
admins systems, j'en aurait entendu parlé.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

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

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

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,

Là, on se répète. Effectivement par design, systemd n'est pas conçu pour
ordonnancer le démarrage. Donc, je ne vais pas dire que j'en suis
surpris.

voire de les renommer.

Oui, il les renomme, mais quand j'ai cherché à comprendre, j'ai vu des
explications qui semblaient prédictibles et effectivement, le nom de mes
interfaces réseau était prévu. Maintenant, sur mon laptop j'ai pas
ouatmillion d'interface réseau. Pour les routeurs/firewall/F5 et tous
les équipements réseau, je ne sais pas s'il y a du systemd dedans, mais
si à chaque démarrage il fallait tout reconfiguré parce que tout avait
été renommé ça se verrait.

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.

À ton boulot, tu as la chance d'être devant une machine pour faire
de la maintenance.

Non, moi je ne fais pas de maintenance. Mais je bosse avec des gens qui
font de la maintenance. Et ils ne sont pas derrière le serveur. Ils
peuvent avoir accès au serveur, mais pour ça il faut qu'ils se
déplacent. Ce qu'ils évitent de faire, surtout pendant le confinement.

Dans le mien, la machine est potentiellement à 1000 km sans
possibilité d'intervenir dessus.

Tu crois que le DRP est dans la même salle que les serveurs qu'il
redonde ? Tu crois que dans une grosse boîte les admins ont leurs
serveurs dédiés à portée de main ?

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.

Nous non plus mais on fait tout pour l'éviter.

La migration se fait à chaud chez le client sur ses heures de
boulot. Ça _doit_ marcher.

Tu crois qu'une grosse boîte perd combien de million par jour quand
Internet tombe ? Il n'y a pas intérêt que ce soit un con qui ait fait
une manip à l'arrache sur un serveur quand tout tombe.

Dans une grosse boîte, ce genre de problème est limité parce que
l'infrastructure est beaucoup plus importante.

Les deux fois où j'ai entendu un mec faire tomber la prod parce qu'il
croyait être en préprod, je t'assure que ça a eu des conséquences. Et
pas que pour lui (c'était pas deux fois le même). Une fois c'était les
DNS qui étaient flingués une fois c'était l'ERP en pleine cloture
comptable.

Je ne sais pas si tu imagines les conséquences d'un plantage d'ERP en
pleine clôture comptable (une destruction de la BDD, il fallait repartir
des sauvegardes) mais je sais que je n'ai pas besoin de t'expliquer les
conséquences d'une suppression des DNS de la boîte.

Dans une grosse boîte, les virements bancaires sont envoyés au dernier
moment. Parce que l'argent est placé avant virement. Et il y a des
grosses pénalités si le virement est en retard. Il n'y a pas intérêt que
le réseau plante au moment du virement : ça coûte très cher.

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.

T'as d'autres problèmes, lorsque t'as plein d'équipements avec des
équipes différentes qui gèrent les équipements, la modification d'un
équipement a souvent des conséquences imprévues et dures à trouver.

Quand c'est la femme de ménage qui débranche un rack pour brancher son
aspirateur, la cause est assez rapide à trouver bien qu'il faille se
déplacer. Mais quand c'est un système de backup qui prend la main toutes
les cinq minutes alors que c'était pas prévu et que les commandes de
haut niveau ne remontent pas les mêmes infos que les commandes de de bas
niveau, je t'assure que c'est dur à déterminer. Et c'était pas lié à
systemd, c'était la mise à jour du backup à partir du système maître qui
n'a pas été faite.

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.

Je ne lis pas l'avenir et je ne peux pas prédire la pérennité de la
boîte. Mais ça m'étonnerait que ce soit une merde sur systemd qui la
fasse couler. Il y a beaucoup d'autres sujet plus inquiétant avant ça.

Il n'y a pas que systemd qui puisse poser des gros problèmes. Et
aujourd'hui, avec le confinement il y a des vraies complexités. Alors un
systemd qui pourrait potentiellement poser problème bien qu'il n'en ait
jamais vraiment posé, ben c'est pas la priorité. La priorité c'est la
vraie vie avec les problèmes actuels à résoudre.

Parce que quand tout le monde est confiné, les accès se font tous depuis
l'extérieur. Les salles de réunion ne sont plus utilisées, donc tout le
monde utilise l'audio et la vidéoconférence. Et là, l'infra elle a
intérêt à tenir.

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.

Pas plus que de sortir que dans une grosse boite chaque reboot est fait
avec un mec au cul de la machine qui va analyser chaque daemon et
cliquer sur reset jusqu'à ce que ça marche. Personne n'a le temps
pour ça. L'écosystème est super complexe et il y a plein de choses
automatisées.

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.

Non seulement il n'y a personne derrière les machines qui sont dans des
salles serveurs ou sur le cloud, mais en plus, il n'y a personne qui
regarde les daemons. Déjà on essaye de se battre avec l'infra pour
savoir avant l'utilisateur final quand un _service_ tombe (ie : pour que
l'application web marche il faut que le serveur de BDD tourne, que le
serveur applicatif tourne et soit connecté à sa BDD et que le réseau
soit OK). Alors pour le suivi des daemons, désolé, mais les outils de
supervisions le permettent mais personne ne les analyse quand ça marche
globalement.

Il y a des sauvegardes, il y a des arrêts et redémarrages automatisés
de serveurs. Pour passer des patchs de sécurité aussi. Et si systemd
plantait tous les serveurs aussi souvent et systématiquement que tu le
dis sur tous nos serveurs, ce serait la guerre tous les jours.

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.

Je ne sais pas ce qui te fais imaginer que les gens sont au cul des
machines. Les serveurs quand ils ne sont pas dans le cloud, ils sont
dans des salles machines dans des racks et virtualisés. Si tu éteints
l'ESX à l'envie parce que t'as un daemon qui freeze une VM tu ne sais
même pas quelles seront les conséquences.

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.

Merci donc de m'avoir confirmé que si systemd c'était l'horreur pour nos
admins systems, j'en aurait entendu parlé.

--
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 14:58:49 GMT,
Stéphane CARPENTIER écrivait :
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,

Là, on se répète. Effectivement par design, systemd n'est pas conçu pour
ordonnancer le démarrage. Donc, je ne vais pas dire que j'en suis
surpris.

voire de les renommer.

Oui, il les renomme, mais quand j'ai cherché à comprendre, j'ai vu des
explications qui semblaient prédictibles et effectivement, le nom de mes
interfaces réseau était prévu. Maintenant, sur mon laptop j'ai pas
ouatmillion d'interface réseau. Pour les routeurs/firewall/F5 et tous
les équipements réseau, je ne sais pas s'il y a du systemd dedans, mais
si à chaque démarrage il fallait tout reconfiguré parce que tout avait
été renommé ça se verrait.

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.

À ton boulot, tu as la chance d'être devant une machine pour faire
de la maintenance.

Non, moi je ne fais pas de maintenance. Mais je bosse avec des gens qui
font de la maintenance. Et ils ne sont pas derrière le serveur. Ils
peuvent avoir accès au serveur, mais pour ça il faut qu'ils se
déplacent. Ce qu'ils évitent de faire, surtout pendant le confinement.

Dans le mien, la machine est potentiellement à 1000 km sans
possibilité d'intervenir dessus.

Tu crois que le DRP est dans la même salle que les serveurs qu'il
redonde ? Tu crois que dans une grosse boîte les admins ont leurs
serveurs dédiés à portée de main ?

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.

Nous non plus mais on fait tout pour l'éviter.

La migration se fait à chaud chez le client sur ses heures de
boulot. Ça _doit_ marcher.

Tu crois qu'une grosse boîte perd combien de million par jour quand
Internet tombe ? Il n'y a pas intérêt que ce soit un con qui ait fait
une manip à l'arrache sur un serveur quand tout tombe.

Dans une grosse boîte, ce genre de problème est limité parce que
l'infrastructure est beaucoup plus importante.

Les deux fois où j'ai entendu un mec faire tomber la prod parce qu'il
croyait être en préprod, je t'assure que ça a eu des conséquences. Et
pas que pour lui (c'était pas deux fois le même). Une fois c'était les
DNS qui étaient flingués une fois c'était l'ERP en pleine cloture
comptable.
Je ne sais pas si tu imagines les conséquences d'un plantage d'ERP en
pleine clôture comptable (une destruction de la BDD, il fallait repartir
des sauvegardes) mais je sais que je n'ai pas besoin de t'expliquer les
conséquences d'une suppression des DNS de la boîte.
Dans une grosse boîte, les virements bancaires sont envoyés au dernier
moment. Parce que l'argent est placé avant virement. Et il y a des
grosses pénalités si le virement est en retard. Il n'y a pas intérêt que
le réseau plante au moment du virement : ça coûte très cher.

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.

T'as d'autres problèmes, lorsque t'as plein d'équipements avec des
équipes différentes qui gèrent les équipements, la modification d'un
équipement a souvent des conséquences imprévues et dures à trouver.
Quand c'est la femme de ménage qui débranche un rack pour brancher son
aspirateur, la cause est assez rapide à trouver bien qu'il faille se
déplacer. Mais quand c'est un système de backup qui prend la main toutes
les cinq minutes alors que c'était pas prévu et que les commandes de
haut niveau ne remontent pas les mêmes infos que les commandes de de bas
niveau, je t'assure que c'est dur à déterminer. Et c'était pas lié à
systemd, c'était la mise à jour du backup à partir du système maître qui
n'a pas été faite.

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.

Je ne lis pas l'avenir et je ne peux pas prédire la pérennité de la
boîte. Mais ça m'étonnerait que ce soit une merde sur systemd qui la
fasse couler. Il y a beaucoup d'autres sujet plus inquiétant avant ça.
Il n'y a pas que systemd qui puisse poser des gros problèmes. Et
aujourd'hui, avec le confinement il y a des vraies complexités. Alors un
systemd qui pourrait potentiellement poser problème bien qu'il n'en ait
jamais vraiment posé, ben c'est pas la priorité. La priorité c'est la
vraie vie avec les problèmes actuels à résoudre.
Parce que quand tout le monde est confiné, les accès se font tous depuis
l'extérieur. Les salles de réunion ne sont plus utilisées, donc tout le
monde utilise l'audio et la vidéoconférence. Et là, l'infra elle a
intérêt à tenir.

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.

Pas plus que de sortir que dans une grosse boite chaque reboot est fait
avec un mec au cul de la machine qui va analyser chaque daemon et
cliquer sur reset jusqu'à ce que ça marche. Personne n'a le temps
pour ça. L'écosystème est super complexe et il y a plein de choses
automatisées.

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.

Non seulement il n'y a personne derrière les machines qui sont dans des
salles serveurs ou sur le cloud, mais en plus, il n'y a personne qui
regarde les daemons. Déjà on essaye de se battre avec l'infra pour
savoir avant l'utilisateur final quand un _service_ tombe (ie : pour que
l'application web marche il faut que le serveur de BDD tourne, que le
serveur applicatif tourne et soit connecté à sa BDD et que le réseau
soit OK). Alors pour le suivi des daemons, désolé, mais les outils de
supervisions le permettent mais personne ne les analyse quand ça marche
globalement.
Il y a des sauvegardes, il y a des arrêts et redémarrages automatisés
de serveurs. Pour passer des patchs de sécurité aussi. Et si systemd
plantait tous les serveurs aussi souvent et systématiquement que tu le
dis sur tous nos serveurs, ce serait la guerre tous les jours.

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.

Je ne sais pas ce qui te fais imaginer que les gens sont au cul des
machines. Les serveurs quand ils ne sont pas dans le cloud, ils sont
dans des salles machines dans des racks et virtualisés. Si tu éteints
l'ESX à l'envie parce que t'as un daemon qui freeze une VM tu ne sais
même pas quelles seront les conséquences.

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.

Merci donc de m'avoir confirmé que si systemd c'était l'horreur pour nos
admins systems, j'en aurait entendu parlé.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

Nicolas George

06/06/2020 à 21:13

Stéphane CARPENTIER , dans le message
, a écrit :

Là, on se répète. Effectivement par design, systemd n'est pas conçu pour
ordonnancer le démarrage.

En fait, si on y tient vraiment, on peut parfaitement décider l'ordre de
lancement des services avec systemd : il suffit de mettre des directives
Requires et After à tous les services.
Mais quel intérêt ?

JKB

06/06/2020 à 21:27

Le 06 Jun 2020 18:50:15 GMT,
Stéphane CARPENTIER écrivait :

Le 06-06-2020, JKB a écrit :
Le 06 Jun 2020 14:58:49 GMT,
Stéphane CARPENTIER écrivait :
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,

Là, on se répète. Effectivement par design, systemd n'est pas conçu pour
ordonnancer le démarrage. Donc, je ne vais pas dire que j'en suis
surpris.
voire de les renommer.

Oui, il les renomme, mais quand j'ai cherché à comprendre, j'ai vu des
explications qui semblaient prédictibles et effectivement, le nom de mes
interfaces réseau était prévu.

Ça, c'est en absence de bug. Il y a eu une mouture du bousin qui
n'interragissait pas correctement avec udev et qui donnait un
résultat folklorique. Par design, systemd est un nid à bugs parce
qu'il est tout sauf simple et trivial.

Maintenant, sur mon laptop j'ai pas
ouatmillion d'interface réseau. Pour les routeurs/firewall/F5 et tous
les équipements réseau, je ne sais pas s'il y a du systemd dedans, mais
si à chaque démarrage il fallait tout reconfiguré parce que tout avait
été renommé ça se verrait.

Tu le vois lors d'un redémarrage. Ces machines sont rarement
redémarrées.

Non, moi je ne fais pas de maintenance. Mais je bosse avec des gens qui
font de la maintenance. Et ils ne sont pas derrière le serveur. Ils
peuvent avoir accès au serveur, mais pour ça il faut qu'ils se
déplacent. Ce qu'ils évitent de faire, surtout pendant le confinement.
Dans le mien, la machine est potentiellement à 1000 km sans
possibilité d'intervenir dessus.

Tu crois que le DRP est dans la même salle que les serveurs qu'il
redonde ? Tu crois que dans une grosse boîte les admins ont leurs
serveurs dédiés à portée de main ?

Ce n'est pas du tout ce que j'ai écrit.

La migration se fait à chaud chez le client sur ses heures de
boulot. Ça _doit_ marcher.

Tu crois qu'une grosse boîte perd combien de million par jour quand
Internet tombe ? Il n'y a pas intérêt que ce soit un con qui ait fait
une manip à l'arrache sur un serveur quand tout tombe.

Ce n'est pas vrai, tu le fait exprès. Une grosse boîte à les moyens
d'avoir des serveurs de test sur lesquels tu peux vérifier que telle
migration se passe bien. La PME du coin ne se paie pas ce luxe. La
migration, tu la fais sans filet. En d'autres termes, la grosse
boîte, si une migration se passe mal, ne peut s'en prendre qu'à
elle-même. La PME, ce n'est pas le même discours. Tu as de la chance
quand tu as une vague machine qui peut servir de serveur de secours
en cas de panne.

Dans une grosse boîte, ce genre de problème est limité parce que
l'infrastructure est beaucoup plus importante.

Les deux fois où j'ai entendu un mec faire tomber la prod parce qu'il
croyait être en préprod, je t'assure que ça a eu des conséquences. Et
pas que pour lui (c'était pas deux fois le même). Une fois c'était les
DNS qui étaient flingués une fois c'était l'ERP en pleine cloture
comptable.
Je ne sais pas si tu imagines les conséquences d'un plantage d'ERP en
pleine clôture comptable (une destruction de la BDD, il fallait repartir
des sauvegardes) mais je sais que je n'ai pas besoin de t'expliquer les
conséquences d'une suppression des DNS de la boîte.
Dans une grosse boîte, les virements bancaires sont envoyés au dernier
moment. Parce que l'argent est placé avant virement. Et il y a des
grosses pénalités si le virement est en retard. Il n'y a pas intérêt que
le réseau plante au moment du virement : ça coûte très cher.

Une grosse boîte a les moyens d'éviter ce genre de chose. Et sinon,
pour ta gouverne, je suis chef d'entreprise, j'ai une vague idée du
merdier qui est derrière un plantage d'ERP.

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.

T'as d'autres problèmes, lorsque t'as plein d'équipements avec des
équipes différentes qui gèrent les équipements, la modification d'un
équipement a souvent des conséquences imprévues et dures à trouver.

Encore une fois, ce n'est pas ce que j'ai écrit. Je t'ai écrit que
lorsque tu as peu de services par machine, systemd est bien plus
prévisible que lorsque ta configuration est complexe, avec tout un
tas de services à démarrer dans l'ordre. Là, systemd est à la
ramasse une version sur deux. Tiens, dans les trucs complexes pas
encore élucidé, j'ai une réplication mariadb que systemd est infoutu
de lancer correctement parce qu'il y a un timeout qui traîne et que
je n'ai pas encore identifié. Systemd dans sa grande bonté lance
tout en même temps, sauf que le master mariadb est sur un vpn à
l'autre bout de la France... Le temps d'établir le VPN, systemd
tue mariadb sur le slave parce qu'il considère qu'il n'a pas démarré
assez vite. Désopilant !

Quand c'est la femme de ménage qui débranche un rack pour brancher son
aspirateur, la cause est assez rapide à trouver bien qu'il faille se
déplacer. Mais quand c'est un système de backup qui prend la main toutes
les cinq minutes alors que c'était pas prévu et que les commandes de
haut niveau ne remontent pas les mêmes infos que les commandes de de bas
niveau, je t'assure que c'est dur à déterminer. Et c'était pas lié à
systemd, c'était la mise à jour du backup à partir du système maître qui
n'a pas été faite.
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.

Je ne lis pas l'avenir et je ne peux pas prédire la pérennité de la
boîte. Mais ça m'étonnerait que ce soit une merde sur systemd qui la
fasse couler. Il y a beaucoup d'autres sujet plus inquiétant avant ça.

Sauf qu'un merde de type systemd à récupérer sur 4000 caisses
enregistreuses Toshiba sur l'ensemble de la France, ça coule une
boîte un peu fragile. Mais il y a effectivement plein d'autres
raisons de planter une boîte.

Il n'y a pas que systemd qui puisse poser des gros problèmes. Et
aujourd'hui, avec le confinement il y a des vraies complexités. Alors un
systemd qui pourrait potentiellement poser problème bien qu'il n'en ait
jamais vraiment posé, ben c'est pas la priorité. La priorité c'est la
vraie vie avec les problèmes actuels à résoudre.
Parce que quand tout le monde est confiné, les accès se font tous depuis
l'extérieur. Les salles de réunion ne sont plus utilisées, donc tout le
monde utilise l'audio et la vidéoconférence. Et là, l'infra elle a
intérêt à tenir.
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.

Pas plus que de sortir que dans une grosse boite chaque reboot est fait
avec un mec au cul de la machine qui va analyser chaque daemon et
cliquer sur reset jusqu'à ce que ça marche. Personne n'a le temps
pour ça. L'écosystème est super complexe et il y a plein de choses
automatisées.

Je me demande si tu le fait exprès ou si tu es totalement débile.
Dans une grosse boîte, tu as toujours un accès à tes serveurs (KVM,
bandeau APC ou autre). Tu peux toujours in fine récupérer la main
sur une machine physiquement ou comme si tu étais physiquement
devant. C'est un cas très particulier et très confortable. Dans la
majorité des cas, tu es contraint de faire confiance à init pour
redémarrer correctement les machines distantes.

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.

Non seulement il n'y a personne derrière les machines qui sont dans des
salles serveurs ou sur le cloud, mais en plus, il n'y a personne qui
regarde les daemons.

Le monitoring, tu n'as jamais entendu parler de cela ? Moi, sur les
pauvres serveurs de ma boîte, j'ai des alertes qui remontent si tel
ou tel service ne fonctionne pas. Ça m'étonnerait beaucoup que ce ne
soit pas le cas sur les infrastructures des grosses boîtes.

Déjà on essaye de se battre avec l'infra pour
savoir avant l'utilisateur final quand un _service_ tombe (ie : pour que
l'application web marche il faut que le serveur de BDD tourne, que le
serveur applicatif tourne et soit connecté à sa BDD et que le réseau
soit OK). Alors pour le suivi des daemons, désolé, mais les outils de
supervisions le permettent mais personne ne les analyse quand ça marche
globalement.
Il y a des sauvegardes, il y a des arrêts et redémarrages automatisés
de serveurs. Pour passer des patchs de sécurité aussi. Et si systemd
plantait tous les serveurs aussi souvent et systématiquement que tu le
dis sur tous nos serveurs, ce serait la guerre tous les jours.
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.

Je ne sais pas ce qui te fais imaginer que les gens sont au cul des
machines. Les serveurs quand ils ne sont pas dans le cloud, ils sont
dans des salles machines dans des racks et virtualisés. Si tu éteints
l'ESX à l'envie parce que t'as un daemon qui freeze une VM tu ne sais
même pas quelles seront les conséquences.
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.

Merci donc de m'avoir confirmé que si systemd c'était l'horreur pour nos
admins systems, j'en aurait entendu parlé.

Mais tu choisis les poisons que tu veux, mon grand. Personnellement,
j'ai vu assez de merde avec cette horreur que je la vire dès que
possible, quitte à virer Linux. Le fait que tu n'aies jamais vu un
problème ne signifie pas qu'il n'y en a pas. Tu as la chance d'avoir
une foultitude de machines qui sont chacunes dans des configurations
assez simples, c'est un cas priviligié. La PME du coin entasse tout
sur le même serveur, sans virtualisation, brut de fonderie. Et là,
systemd est une calamité pleine d'effets de bord rigolos ou
catastrophiques.
Fin de la discussion.
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 18:50:15 GMT,
Stéphane CARPENTIER <sc@fiat-linux.fr> écrivait :

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

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

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,

Là, on se répète. Effectivement par design, systemd n'est pas conçu pour
ordonnancer le démarrage. Donc, je ne vais pas dire que j'en suis
surpris.

voire de les renommer.

Oui, il les renomme, mais quand j'ai cherché à comprendre, j'ai vu des
explications qui semblaient prédictibles et effectivement, le nom de mes
interfaces réseau était prévu.

Ça, c'est en absence de bug. Il y a eu une mouture du bousin qui
n'interragissait pas correctement avec udev et qui donnait un
résultat folklorique. Par design, systemd est un nid à bugs parce
qu'il est tout sauf simple et trivial.

Maintenant, sur mon laptop j'ai pas
ouatmillion d'interface réseau. Pour les routeurs/firewall/F5 et tous
les équipements réseau, je ne sais pas s'il y a du systemd dedans, mais
si à chaque démarrage il fallait tout reconfiguré parce que tout avait
été renommé ça se verrait.

Tu le vois lors d'un redémarrage. Ces machines sont rarement
redémarrées.

Non, moi je ne fais pas de maintenance. Mais je bosse avec des gens qui
font de la maintenance. Et ils ne sont pas derrière le serveur. Ils
peuvent avoir accès au serveur, mais pour ça il faut qu'ils se
déplacent. Ce qu'ils évitent de faire, surtout pendant le confinement.

Dans le mien, la machine est potentiellement à 1000 km sans
possibilité d'intervenir dessus.

Tu crois que le DRP est dans la même salle que les serveurs qu'il
redonde ? Tu crois que dans une grosse boîte les admins ont leurs
serveurs dédiés à portée de main ?

Ce n'est pas du tout ce que j'ai écrit.

La migration se fait à chaud chez le client sur ses heures de
boulot. Ça _doit_ marcher.

Tu crois qu'une grosse boîte perd combien de million par jour quand
Internet tombe ? Il n'y a pas intérêt que ce soit un con qui ait fait
une manip à l'arrache sur un serveur quand tout tombe.

Ce n'est pas vrai, tu le fait exprès. Une grosse boîte à les moyens
d'avoir des serveurs de test sur lesquels tu peux vérifier que telle
migration se passe bien. La PME du coin ne se paie pas ce luxe. La
migration, tu la fais sans filet. En d'autres termes, la grosse
boîte, si une migration se passe mal, ne peut s'en prendre qu'à
elle-même. La PME, ce n'est pas le même discours. Tu as de la chance
quand tu as une vague machine qui peut servir de serveur de secours
en cas de panne.

Dans une grosse boîte, ce genre de problème est limité parce que
l'infrastructure est beaucoup plus importante.

Les deux fois où j'ai entendu un mec faire tomber la prod parce qu'il
croyait être en préprod, je t'assure que ça a eu des conséquences. Et
pas que pour lui (c'était pas deux fois le même). Une fois c'était les
DNS qui étaient flingués une fois c'était l'ERP en pleine cloture
comptable.

Je ne sais pas si tu imagines les conséquences d'un plantage d'ERP en
pleine clôture comptable (une destruction de la BDD, il fallait repartir
des sauvegardes) mais je sais que je n'ai pas besoin de t'expliquer les
conséquences d'une suppression des DNS de la boîte.

Dans une grosse boîte, les virements bancaires sont envoyés au dernier
moment. Parce que l'argent est placé avant virement. Et il y a des
grosses pénalités si le virement est en retard. Il n'y a pas intérêt que
le réseau plante au moment du virement : ça coûte très cher.

Une grosse boîte a les moyens d'éviter ce genre de chose. Et sinon,
pour ta gouverne, je suis chef d'entreprise, j'ai une vague idée du
merdier qui est derrière un plantage d'ERP.

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.

T'as d'autres problèmes, lorsque t'as plein d'équipements avec des
équipes différentes qui gèrent les équipements, la modification d'un
équipement a souvent des conséquences imprévues et dures à trouver.

Encore une fois, ce n'est pas ce que j'ai écrit. Je t'ai écrit que
lorsque tu as peu de services par machine, systemd est bien plus
prévisible que lorsque ta configuration est complexe, avec tout un
tas de services à démarrer dans l'ordre. Là, systemd est à la
ramasse une version sur deux. Tiens, dans les trucs complexes pas
encore élucidé, j'ai une réplication mariadb que systemd est infoutu
de lancer correctement parce qu'il y a un timeout qui traîne et que
je n'ai pas encore identifié. Systemd dans sa grande bonté lance
tout en même temps, sauf que le master mariadb est sur un vpn à
l'autre bout de la France... Le temps d'établir le VPN, systemd
tue mariadb sur le slave parce qu'il considère qu'il n'a pas démarré
assez vite. Désopilant !

Quand c'est la femme de ménage qui débranche un rack pour brancher son
aspirateur, la cause est assez rapide à trouver bien qu'il faille se
déplacer. Mais quand c'est un système de backup qui prend la main toutes
les cinq minutes alors que c'était pas prévu et que les commandes de
haut niveau ne remontent pas les mêmes infos que les commandes de de bas
niveau, je t'assure que c'est dur à déterminer. Et c'était pas lié à
systemd, c'était la mise à jour du backup à partir du système maître qui
n'a pas été faite.

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.

Je ne lis pas l'avenir et je ne peux pas prédire la pérennité de la
boîte. Mais ça m'étonnerait que ce soit une merde sur systemd qui la
fasse couler. Il y a beaucoup d'autres sujet plus inquiétant avant ça.

Sauf qu'un merde de type systemd à récupérer sur 4000 caisses
enregistreuses Toshiba sur l'ensemble de la France, ça coule une
boîte un peu fragile. Mais il y a effectivement plein d'autres
raisons de planter une boîte.

Il n'y a pas que systemd qui puisse poser des gros problèmes. Et
aujourd'hui, avec le confinement il y a des vraies complexités. Alors un
systemd qui pourrait potentiellement poser problème bien qu'il n'en ait
jamais vraiment posé, ben c'est pas la priorité. La priorité c'est la
vraie vie avec les problèmes actuels à résoudre.

Parce que quand tout le monde est confiné, les accès se font tous depuis
l'extérieur. Les salles de réunion ne sont plus utilisées, donc tout le
monde utilise l'audio et la vidéoconférence. Et là, l'infra elle a
intérêt à tenir.

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.

Pas plus que de sortir que dans une grosse boite chaque reboot est fait
avec un mec au cul de la machine qui va analyser chaque daemon et
cliquer sur reset jusqu'à ce que ça marche. Personne n'a le temps
pour ça. L'écosystème est super complexe et il y a plein de choses
automatisées.

Je me demande si tu le fait exprès ou si tu es totalement débile.
Dans une grosse boîte, tu as toujours un accès à tes serveurs (KVM,
bandeau APC ou autre). Tu peux toujours in fine récupérer la main
sur une machine physiquement ou comme si tu étais physiquement
devant. C'est un cas très particulier et très confortable. Dans la
majorité des cas, tu es contraint de faire confiance à init pour
redémarrer correctement les machines distantes.

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.

Non seulement il n'y a personne derrière les machines qui sont dans des
salles serveurs ou sur le cloud, mais en plus, il n'y a personne qui
regarde les daemons.

Le monitoring, tu n'as jamais entendu parler de cela ? Moi, sur les
pauvres serveurs de ma boîte, j'ai des alertes qui remontent si tel
ou tel service ne fonctionne pas. Ça m'étonnerait beaucoup que ce ne
soit pas le cas sur les infrastructures des grosses boîtes.

Déjà on essaye de se battre avec l'infra pour
savoir avant l'utilisateur final quand un _service_ tombe (ie : pour que
l'application web marche il faut que le serveur de BDD tourne, que le
serveur applicatif tourne et soit connecté à sa BDD et que le réseau
soit OK). Alors pour le suivi des daemons, désolé, mais les outils de
supervisions le permettent mais personne ne les analyse quand ça marche
globalement.

Il y a des sauvegardes, il y a des arrêts et redémarrages automatisés
de serveurs. Pour passer des patchs de sécurité aussi. Et si systemd
plantait tous les serveurs aussi souvent et systématiquement que tu le
dis sur tous nos serveurs, ce serait la guerre tous les jours.

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.

Je ne sais pas ce qui te fais imaginer que les gens sont au cul des
machines. Les serveurs quand ils ne sont pas dans le cloud, ils sont
dans des salles machines dans des racks et virtualisés. Si tu éteints
l'ESX à l'envie parce que t'as un daemon qui freeze une VM tu ne sais
même pas quelles seront les conséquences.

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.

Merci donc de m'avoir confirmé que si systemd c'était l'horreur pour nos
admins systems, j'en aurait entendu parlé.

Mais tu choisis les poisons que tu veux, mon grand. Personnellement,
j'ai vu assez de merde avec cette horreur que je la vire dès que
possible, quitte à virer Linux. Le fait que tu n'aies jamais vu un
problème ne signifie pas qu'il n'y en a pas. Tu as la chance d'avoir
une foultitude de machines qui sont chacunes dans des configurations
assez simples, c'est un cas priviligié. La PME du coin entasse tout
sur le même serveur, sans virtualisation, brut de fonderie. Et là,
systemd est une calamité pleine d'effets de bord rigolos ou
catastrophiques.

Fin de la discussion.

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 18:50:15 GMT,
Stéphane CARPENTIER écrivait :

Le 06-06-2020, JKB a écrit :
Le 06 Jun 2020 14:58:49 GMT,
Stéphane CARPENTIER écrivait :
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,

Là, on se répète. Effectivement par design, systemd n'est pas conçu pour
ordonnancer le démarrage. Donc, je ne vais pas dire que j'en suis
surpris.
voire de les renommer.

Oui, il les renomme, mais quand j'ai cherché à comprendre, j'ai vu des
explications qui semblaient prédictibles et effectivement, le nom de mes
interfaces réseau était prévu.

Ça, c'est en absence de bug. Il y a eu une mouture du bousin qui
n'interragissait pas correctement avec udev et qui donnait un
résultat folklorique. Par design, systemd est un nid à bugs parce
qu'il est tout sauf simple et trivial.

Maintenant, sur mon laptop j'ai pas
ouatmillion d'interface réseau. Pour les routeurs/firewall/F5 et tous
les équipements réseau, je ne sais pas s'il y a du systemd dedans, mais
si à chaque démarrage il fallait tout reconfiguré parce que tout avait
été renommé ça se verrait.

Tu le vois lors d'un redémarrage. Ces machines sont rarement
redémarrées.

Non, moi je ne fais pas de maintenance. Mais je bosse avec des gens qui
font de la maintenance. Et ils ne sont pas derrière le serveur. Ils
peuvent avoir accès au serveur, mais pour ça il faut qu'ils se
déplacent. Ce qu'ils évitent de faire, surtout pendant le confinement.
Dans le mien, la machine est potentiellement à 1000 km sans
possibilité d'intervenir dessus.

Tu crois que le DRP est dans la même salle que les serveurs qu'il
redonde ? Tu crois que dans une grosse boîte les admins ont leurs
serveurs dédiés à portée de main ?

Ce n'est pas du tout ce que j'ai écrit.

La migration se fait à chaud chez le client sur ses heures de
boulot. Ça _doit_ marcher.

Tu crois qu'une grosse boîte perd combien de million par jour quand
Internet tombe ? Il n'y a pas intérêt que ce soit un con qui ait fait
une manip à l'arrache sur un serveur quand tout tombe.

Ce n'est pas vrai, tu le fait exprès. Une grosse boîte à les moyens
d'avoir des serveurs de test sur lesquels tu peux vérifier que telle
migration se passe bien. La PME du coin ne se paie pas ce luxe. La
migration, tu la fais sans filet. En d'autres termes, la grosse
boîte, si une migration se passe mal, ne peut s'en prendre qu'à
elle-même. La PME, ce n'est pas le même discours. Tu as de la chance
quand tu as une vague machine qui peut servir de serveur de secours
en cas de panne.

Dans une grosse boîte, ce genre de problème est limité parce que
l'infrastructure est beaucoup plus importante.

Les deux fois où j'ai entendu un mec faire tomber la prod parce qu'il
croyait être en préprod, je t'assure que ça a eu des conséquences. Et
pas que pour lui (c'était pas deux fois le même). Une fois c'était les
DNS qui étaient flingués une fois c'était l'ERP en pleine cloture
comptable.
Je ne sais pas si tu imagines les conséquences d'un plantage d'ERP en
pleine clôture comptable (une destruction de la BDD, il fallait repartir
des sauvegardes) mais je sais que je n'ai pas besoin de t'expliquer les
conséquences d'une suppression des DNS de la boîte.
Dans une grosse boîte, les virements bancaires sont envoyés au dernier
moment. Parce que l'argent est placé avant virement. Et il y a des
grosses pénalités si le virement est en retard. Il n'y a pas intérêt que
le réseau plante au moment du virement : ça coûte très cher.

Une grosse boîte a les moyens d'éviter ce genre de chose. Et sinon,
pour ta gouverne, je suis chef d'entreprise, j'ai une vague idée du
merdier qui est derrière un plantage d'ERP.

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.

T'as d'autres problèmes, lorsque t'as plein d'équipements avec des
équipes différentes qui gèrent les équipements, la modification d'un
équipement a souvent des conséquences imprévues et dures à trouver.

Encore une fois, ce n'est pas ce que j'ai écrit. Je t'ai écrit que
lorsque tu as peu de services par machine, systemd est bien plus
prévisible que lorsque ta configuration est complexe, avec tout un
tas de services à démarrer dans l'ordre. Là, systemd est à la
ramasse une version sur deux. Tiens, dans les trucs complexes pas
encore élucidé, j'ai une réplication mariadb que systemd est infoutu
de lancer correctement parce qu'il y a un timeout qui traîne et que
je n'ai pas encore identifié. Systemd dans sa grande bonté lance
tout en même temps, sauf que le master mariadb est sur un vpn à
l'autre bout de la France... Le temps d'établir le VPN, systemd
tue mariadb sur le slave parce qu'il considère qu'il n'a pas démarré
assez vite. Désopilant !

Quand c'est la femme de ménage qui débranche un rack pour brancher son
aspirateur, la cause est assez rapide à trouver bien qu'il faille se
déplacer. Mais quand c'est un système de backup qui prend la main toutes
les cinq minutes alors que c'était pas prévu et que les commandes de
haut niveau ne remontent pas les mêmes infos que les commandes de de bas
niveau, je t'assure que c'est dur à déterminer. Et c'était pas lié à
systemd, c'était la mise à jour du backup à partir du système maître qui
n'a pas été faite.
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.

Je ne lis pas l'avenir et je ne peux pas prédire la pérennité de la
boîte. Mais ça m'étonnerait que ce soit une merde sur systemd qui la
fasse couler. Il y a beaucoup d'autres sujet plus inquiétant avant ça.

Sauf qu'un merde de type systemd à récupérer sur 4000 caisses
enregistreuses Toshiba sur l'ensemble de la France, ça coule une
boîte un peu fragile. Mais il y a effectivement plein d'autres
raisons de planter une boîte.

Il n'y a pas que systemd qui puisse poser des gros problèmes. Et
aujourd'hui, avec le confinement il y a des vraies complexités. Alors un
systemd qui pourrait potentiellement poser problème bien qu'il n'en ait
jamais vraiment posé, ben c'est pas la priorité. La priorité c'est la
vraie vie avec les problèmes actuels à résoudre.
Parce que quand tout le monde est confiné, les accès se font tous depuis
l'extérieur. Les salles de réunion ne sont plus utilisées, donc tout le
monde utilise l'audio et la vidéoconférence. Et là, l'infra elle a
intérêt à tenir.
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.

Pas plus que de sortir que dans une grosse boite chaque reboot est fait
avec un mec au cul de la machine qui va analyser chaque daemon et
cliquer sur reset jusqu'à ce que ça marche. Personne n'a le temps
pour ça. L'écosystème est super complexe et il y a plein de choses
automatisées.

Je me demande si tu le fait exprès ou si tu es totalement débile.
Dans une grosse boîte, tu as toujours un accès à tes serveurs (KVM,
bandeau APC ou autre). Tu peux toujours in fine récupérer la main
sur une machine physiquement ou comme si tu étais physiquement
devant. C'est un cas très particulier et très confortable. Dans la
majorité des cas, tu es contraint de faire confiance à init pour
redémarrer correctement les machines distantes.

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.

Non seulement il n'y a personne derrière les machines qui sont dans des
salles serveurs ou sur le cloud, mais en plus, il n'y a personne qui
regarde les daemons.

Le monitoring, tu n'as jamais entendu parler de cela ? Moi, sur les
pauvres serveurs de ma boîte, j'ai des alertes qui remontent si tel
ou tel service ne fonctionne pas. Ça m'étonnerait beaucoup que ce ne
soit pas le cas sur les infrastructures des grosses boîtes.

Déjà on essaye de se battre avec l'infra pour
savoir avant l'utilisateur final quand un _service_ tombe (ie : pour que
l'application web marche il faut que le serveur de BDD tourne, que le
serveur applicatif tourne et soit connecté à sa BDD et que le réseau
soit OK). Alors pour le suivi des daemons, désolé, mais les outils de
supervisions le permettent mais personne ne les analyse quand ça marche
globalement.
Il y a des sauvegardes, il y a des arrêts et redémarrages automatisés
de serveurs. Pour passer des patchs de sécurité aussi. Et si systemd
plantait tous les serveurs aussi souvent et systématiquement que tu le
dis sur tous nos serveurs, ce serait la guerre tous les jours.
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.

Je ne sais pas ce qui te fais imaginer que les gens sont au cul des
machines. Les serveurs quand ils ne sont pas dans le cloud, ils sont
dans des salles machines dans des racks et virtualisés. Si tu éteints
l'ESX à l'envie parce que t'as un daemon qui freeze une VM tu ne sais
même pas quelles seront les conséquences.
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.

Merci donc de m'avoir confirmé que si systemd c'était l'horreur pour nos
admins systems, j'en aurait entendu parlé.

Mais tu choisis les poisons que tu veux, mon grand. Personnellement,
j'ai vu assez de merde avec cette horreur que je la vire dès que
possible, quitte à virer Linux. Le fait que tu n'aies jamais vu un
problème ne signifie pas qu'il n'y en a pas. Tu as la chance d'avoir
une foultitude de machines qui sont chacunes dans des configurations
assez simples, c'est un cas priviligié. La PME du coin entasse tout
sur le même serveur, sans virtualisation, brut de fonderie. Et là,
systemd est une calamité pleine d'effets de bord rigolos ou
catastrophiques.
Fin de la discussion.
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 à 23:15

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

Le 06 Jun 2020 10:41:26 GMT,
Stéphane CARPENTIER écrivait :
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.

OK, bonne idée.
J'ai deux ordinateurs chez moi. Un vieil ubuntu 17.10 avec un celeron
deux cœurs et 8Go. Au niveau m&moire ça tient la route, mais pour ce
qui est performance, c'est pas glorieux, il y a gnome et KDE. Même si
j'utilise i3 dessus, les deux autres sont quand même installés et se
posent des problèmes. Je n'y touche pas car comme c'est celui sur lequel
il y a mon serveur de mails, j'ai pas envie de risquer de tout casser.
Je fais htop, je cherche le process 1. Il faut le chercher parce par
défaut il n'apparait pas. Résultat : CPU% 0.0 et MEM% 0.1
Donc, merci de m'avoir permis de confirmer ce qui était une évidence, ce
n'est pas le process 1 qui fait ramer la machine. par contre des process
qui prennent des ressources, avec Firefox, j'atteins rapidement 100% sur
les deux cœurs.
C'est rigolo parce que sur mon laptop 8cœurs 16Go avec Arch sans aucune
ubuntuerie j'ai exactement le même résultat. Je sais, mettre ubuntu sur
le serveur de mail et Arch sur le laptop peut surprendre mais c'est
historique.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

Stéphane CARPENTIER

06/06/2020 à 23:49

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

Le 06 Jun 2020 18:50:15 GMT,
Stéphane CARPENTIER écrivait :
Le 06-06-2020, JKB a écrit :
Le 06 Jun 2020 14:58:49 GMT,
voire de les renommer.

Oui, il les renomme, mais quand j'ai cherché à comprendre, j'ai vu des
explications qui semblaient prédictibles et effectivement, le nom de mes
interfaces réseau était prévu.

Ça, c'est en absence de bug. Il y a eu une mouture du bousin qui
n'interragissait pas correctement avec udev et qui donnait un
résultat folklorique. Par design, systemd est un nid à bugs parce
qu'il est tout sauf simple et trivial.

Je sais, en théorie ça devrait péter tous les jours dans dans tous les
sens. Mais en pratique ce n'est pas le cas.

Maintenant, sur mon laptop j'ai pas
ouatmillion d'interface réseau. Pour les routeurs/firewall/F5 et tous
les équipements réseau, je ne sais pas s'il y a du systemd dedans, mais
si à chaque démarrage il fallait tout reconfiguré parce que tout avait
été renommé ça se verrait.

Tu le vois lors d'un redémarrage. Ces machines sont rarement
redémarrées.

Sisi, certaines machines sont redémarrées tous les jours, d'autres
toutes les semaines.

La migration se fait à chaud chez le client sur ses heures de
boulot. Ça _doit_ marcher.

Tu crois qu'une grosse boîte perd combien de million par jour quand
Internet tombe ? Il n'y a pas intérêt que ce soit un con qui ait fait
une manip à l'arrache sur un serveur quand tout tombe.

Ce n'est pas vrai, tu le fait exprès. Une grosse boîte à les moyens
d'avoir des serveurs de test sur lesquels tu peux vérifier que telle
migration se passe bien.

C'est une question de moyens, de volonté, d'historique. La grosse boîte
choisit aussi de prioriser certains projets. Il y a plein de chose qui
font qu'un serveur de test iso qui garanti la migration à 100% n'est pas
toujours possible.

En d'autres termes, la grosse boîte, si une migration se passe mal,
ne peut s'en prendre qu'à elle-même.

Ça, c'est la théorie. En pratique c'est pas forcément vrai.

Dans une grosse boîte, ce genre de problème est limité parce que
l'infrastructure est beaucoup plus importante.

Les deux fois où j'ai entendu un mec faire tomber la prod parce qu'il
croyait être en préprod, je t'assure que ça a eu des conséquences. Et
pas que pour lui (c'était pas deux fois le même). Une fois c'était les
DNS qui étaient flingués une fois c'était l'ERP en pleine cloture
comptable.
Je ne sais pas si tu imagines les conséquences d'un plantage d'ERP en
pleine clôture comptable (une destruction de la BDD, il fallait repartir
des sauvegardes) mais je sais que je n'ai pas besoin de t'expliquer les
conséquences d'une suppression des DNS de la boîte.
Dans une grosse boîte, les virements bancaires sont envoyés au dernier
moment. Parce que l'argent est placé avant virement. Et il y a des
grosses pénalités si le virement est en retard. Il n'y a pas intérêt que
le réseau plante au moment du virement : ça coûte très cher.

Une grosse boîte a les moyens d'éviter ce genre de chose. Et sinon,
pour ta gouverne, je suis chef d'entreprise, j'ai une vague idée du
merdier qui est derrière un plantage d'ERP.

Donc tu dois savoir qu'un ERP d'une grosse boîte c'est pas juste un mec
derrière son serveur mais ça implique des dizaines de mecs derrière des
dizaines de serveurs. Et tu dois aussi savoir qu'il ne suffit pas de
dire qu'il n'y a qu'à mettre un serveur de test pour que ça marche. Plus
il y a d'intervenants impliqués, plus il y a de risques.

Dans une grosse boîte, tu as toujours un accès à tes serveurs (KVM,
bandeau APC ou autre). Tu peux toujours in fine récupérer la main
sur une machine physiquement ou comme si tu étais physiquement
devant.

Et alors ? Ils n'ont pas que ça à faire d'y aller. S'ils ont besoin d'y
aller, c'est que c'est la guerre. Donc savoir que ça peut aider
n'apporte rien.

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.

Non seulement il n'y a personne derrière les machines qui sont dans des
salles serveurs ou sur le cloud, mais en plus, il n'y a personne qui
regarde les daemons.

Le monitoring, tu n'as jamais entendu parler de cela ? Moi, sur les
pauvres serveurs de ma boîte, j'ai des alertes qui remontent si tel
ou tel service ne fonctionne pas. Ça m'étonnerait beaucoup que ce ne
soit pas le cas sur les infrastructures des grosses boîtes.

Bien sûr que si qu'il y a du monitoring. Mais ils n'ont pas le temps
d'analyser tout ce qui marche pour savoir si ça marche aussi bien que
prévu. Si le service est rendu, ils s'occupent de ce qui ne marche pas
ou de ce qui risque de poser problème, c'est suffisant.

Merci donc de m'avoir confirmé que si systemd c'était l'horreur pour nos
admins systems, j'en aurait entendu parlé.

Mais tu choisis les poisons que tu veux, mon grand.

C'est pas moi qui choisis (sauf pour chez moi). Mais je vois les
conséquences des choix des autres. Et les gros problèmes, ils sont pas
portés par systemd.

Le fait que tu n'aies jamais vu un problème ne signifie pas qu'il
n'y en a pas.

Je sais, c'est ce que j'ai écris. Il y en a fort probablement, mais par
rapports à tous les problèmes, ils sont mineurs.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

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

Le 06 Jun 2020 18:50:15 GMT,
Stéphane CARPENTIER <sc@fiat-linux.fr> écrivait :

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

Le 06 Jun 2020 14:58:49 GMT,
voire de les renommer.

Oui, il les renomme, mais quand j'ai cherché à comprendre, j'ai vu des
explications qui semblaient prédictibles et effectivement, le nom de mes
interfaces réseau était prévu.

Ça, c'est en absence de bug. Il y a eu une mouture du bousin qui
n'interragissait pas correctement avec udev et qui donnait un
résultat folklorique. Par design, systemd est un nid à bugs parce
qu'il est tout sauf simple et trivial.

Je sais, en théorie ça devrait péter tous les jours dans dans tous les
sens. Mais en pratique ce n'est pas le cas.

Maintenant, sur mon laptop j'ai pas
ouatmillion d'interface réseau. Pour les routeurs/firewall/F5 et tous
les équipements réseau, je ne sais pas s'il y a du systemd dedans, mais
si à chaque démarrage il fallait tout reconfiguré parce que tout avait
été renommé ça se verrait.

Tu le vois lors d'un redémarrage. Ces machines sont rarement
redémarrées.

Sisi, certaines machines sont redémarrées tous les jours, d'autres
toutes les semaines.

La migration se fait à chaud chez le client sur ses heures de
boulot. Ça _doit_ marcher.

Tu crois qu'une grosse boîte perd combien de million par jour quand
Internet tombe ? Il n'y a pas intérêt que ce soit un con qui ait fait
une manip à l'arrache sur un serveur quand tout tombe.

Ce n'est pas vrai, tu le fait exprès. Une grosse boîte à les moyens
d'avoir des serveurs de test sur lesquels tu peux vérifier que telle
migration se passe bien.

C'est une question de moyens, de volonté, d'historique. La grosse boîte
choisit aussi de prioriser certains projets. Il y a plein de chose qui
font qu'un serveur de test iso qui garanti la migration à 100% n'est pas
toujours possible.

En d'autres termes, la grosse boîte, si une migration se passe mal,
ne peut s'en prendre qu'à elle-même.

Ça, c'est la théorie. En pratique c'est pas forcément vrai.

Dans une grosse boîte, ce genre de problème est limité parce que
l'infrastructure est beaucoup plus importante.

Les deux fois où j'ai entendu un mec faire tomber la prod parce qu'il
croyait être en préprod, je t'assure que ça a eu des conséquences. Et
pas que pour lui (c'était pas deux fois le même). Une fois c'était les
DNS qui étaient flingués une fois c'était l'ERP en pleine cloture
comptable.

Je ne sais pas si tu imagines les conséquences d'un plantage d'ERP en
pleine clôture comptable (une destruction de la BDD, il fallait repartir
des sauvegardes) mais je sais que je n'ai pas besoin de t'expliquer les
conséquences d'une suppression des DNS de la boîte.

Dans une grosse boîte, les virements bancaires sont envoyés au dernier
moment. Parce que l'argent est placé avant virement. Et il y a des
grosses pénalités si le virement est en retard. Il n'y a pas intérêt que
le réseau plante au moment du virement : ça coûte très cher.

Une grosse boîte a les moyens d'éviter ce genre de chose. Et sinon,
pour ta gouverne, je suis chef d'entreprise, j'ai une vague idée du
merdier qui est derrière un plantage d'ERP.

Donc tu dois savoir qu'un ERP d'une grosse boîte c'est pas juste un mec
derrière son serveur mais ça implique des dizaines de mecs derrière des
dizaines de serveurs. Et tu dois aussi savoir qu'il ne suffit pas de
dire qu'il n'y a qu'à mettre un serveur de test pour que ça marche. Plus
il y a d'intervenants impliqués, plus il y a de risques.

Dans une grosse boîte, tu as toujours un accès à tes serveurs (KVM,
bandeau APC ou autre). Tu peux toujours in fine récupérer la main
sur une machine physiquement ou comme si tu étais physiquement
devant.

Et alors ? Ils n'ont pas que ça à faire d'y aller. S'ils ont besoin d'y
aller, c'est que c'est la guerre. Donc savoir que ça peut aider
n'apporte rien.

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.

Non seulement il n'y a personne derrière les machines qui sont dans des
salles serveurs ou sur le cloud, mais en plus, il n'y a personne qui
regarde les daemons.

Le monitoring, tu n'as jamais entendu parler de cela ? Moi, sur les
pauvres serveurs de ma boîte, j'ai des alertes qui remontent si tel
ou tel service ne fonctionne pas. Ça m'étonnerait beaucoup que ce ne
soit pas le cas sur les infrastructures des grosses boîtes.

Bien sûr que si qu'il y a du monitoring. Mais ils n'ont pas le temps
d'analyser tout ce qui marche pour savoir si ça marche aussi bien que
prévu. Si le service est rendu, ils s'occupent de ce qui ne marche pas
ou de ce qui risque de poser problème, c'est suffisant.

Merci donc de m'avoir confirmé que si systemd c'était l'horreur pour nos
admins systems, j'en aurait entendu parlé.

Mais tu choisis les poisons que tu veux, mon grand.

C'est pas moi qui choisis (sauf pour chez moi). Mais je vois les
conséquences des choix des autres. Et les gros problèmes, ils sont pas
portés par systemd.

Le fait que tu n'aies jamais vu un problème ne signifie pas qu'il
n'y en a pas.

Je sais, c'est ce que j'ai écris. Il y en a fort probablement, mais par
rapports à tous les problèmes, ils sont mineurs.

--
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 18:50:15 GMT,
Stéphane CARPENTIER écrivait :
Le 06-06-2020, JKB a écrit :
Le 06 Jun 2020 14:58:49 GMT,
voire de les renommer.

Oui, il les renomme, mais quand j'ai cherché à comprendre, j'ai vu des
explications qui semblaient prédictibles et effectivement, le nom de mes
interfaces réseau était prévu.

Ça, c'est en absence de bug. Il y a eu une mouture du bousin qui
n'interragissait pas correctement avec udev et qui donnait un
résultat folklorique. Par design, systemd est un nid à bugs parce
qu'il est tout sauf simple et trivial.

Je sais, en théorie ça devrait péter tous les jours dans dans tous les
sens. Mais en pratique ce n'est pas le cas.

Maintenant, sur mon laptop j'ai pas
ouatmillion d'interface réseau. Pour les routeurs/firewall/F5 et tous
les équipements réseau, je ne sais pas s'il y a du systemd dedans, mais
si à chaque démarrage il fallait tout reconfiguré parce que tout avait
été renommé ça se verrait.

Tu le vois lors d'un redémarrage. Ces machines sont rarement
redémarrées.

Sisi, certaines machines sont redémarrées tous les jours, d'autres
toutes les semaines.

La migration se fait à chaud chez le client sur ses heures de
boulot. Ça _doit_ marcher.

Tu crois qu'une grosse boîte perd combien de million par jour quand
Internet tombe ? Il n'y a pas intérêt que ce soit un con qui ait fait
une manip à l'arrache sur un serveur quand tout tombe.

Ce n'est pas vrai, tu le fait exprès. Une grosse boîte à les moyens
d'avoir des serveurs de test sur lesquels tu peux vérifier que telle
migration se passe bien.

C'est une question de moyens, de volonté, d'historique. La grosse boîte
choisit aussi de prioriser certains projets. Il y a plein de chose qui
font qu'un serveur de test iso qui garanti la migration à 100% n'est pas
toujours possible.

En d'autres termes, la grosse boîte, si une migration se passe mal,
ne peut s'en prendre qu'à elle-même.

Ça, c'est la théorie. En pratique c'est pas forcément vrai.

Dans une grosse boîte, ce genre de problème est limité parce que
l'infrastructure est beaucoup plus importante.

Les deux fois où j'ai entendu un mec faire tomber la prod parce qu'il
croyait être en préprod, je t'assure que ça a eu des conséquences. Et
pas que pour lui (c'était pas deux fois le même). Une fois c'était les
DNS qui étaient flingués une fois c'était l'ERP en pleine cloture
comptable.
Je ne sais pas si tu imagines les conséquences d'un plantage d'ERP en
pleine clôture comptable (une destruction de la BDD, il fallait repartir
des sauvegardes) mais je sais que je n'ai pas besoin de t'expliquer les
conséquences d'une suppression des DNS de la boîte.
Dans une grosse boîte, les virements bancaires sont envoyés au dernier
moment. Parce que l'argent est placé avant virement. Et il y a des
grosses pénalités si le virement est en retard. Il n'y a pas intérêt que
le réseau plante au moment du virement : ça coûte très cher.

Une grosse boîte a les moyens d'éviter ce genre de chose. Et sinon,
pour ta gouverne, je suis chef d'entreprise, j'ai une vague idée du
merdier qui est derrière un plantage d'ERP.

Donc tu dois savoir qu'un ERP d'une grosse boîte c'est pas juste un mec
derrière son serveur mais ça implique des dizaines de mecs derrière des
dizaines de serveurs. Et tu dois aussi savoir qu'il ne suffit pas de
dire qu'il n'y a qu'à mettre un serveur de test pour que ça marche. Plus
il y a d'intervenants impliqués, plus il y a de risques.

Dans une grosse boîte, tu as toujours un accès à tes serveurs (KVM,
bandeau APC ou autre). Tu peux toujours in fine récupérer la main
sur une machine physiquement ou comme si tu étais physiquement
devant.

Et alors ? Ils n'ont pas que ça à faire d'y aller. S'ils ont besoin d'y
aller, c'est que c'est la guerre. Donc savoir que ça peut aider
n'apporte rien.

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.

Non seulement il n'y a personne derrière les machines qui sont dans des
salles serveurs ou sur le cloud, mais en plus, il n'y a personne qui
regarde les daemons.

Le monitoring, tu n'as jamais entendu parler de cela ? Moi, sur les
pauvres serveurs de ma boîte, j'ai des alertes qui remontent si tel
ou tel service ne fonctionne pas. Ça m'étonnerait beaucoup que ce ne
soit pas le cas sur les infrastructures des grosses boîtes.

Bien sûr que si qu'il y a du monitoring. Mais ils n'ont pas le temps
d'analyser tout ce qui marche pour savoir si ça marche aussi bien que
prévu. Si le service est rendu, ils s'occupent de ce qui ne marche pas
ou de ce qui risque de poser problème, c'est suffisant.

Merci donc de m'avoir confirmé que si systemd c'était l'horreur pour nos
admins systems, j'en aurait entendu parlé.

Mais tu choisis les poisons que tu veux, mon grand.

C'est pas moi qui choisis (sauf pour chez moi). Mais je vois les
conséquences des choix des autres. Et les gros problèmes, ils sont pas
portés par systemd.

Le fait que tu n'aies jamais vu un problème ne signifie pas qu'il
n'y en a pas.

Je sais, c'est ce que j'ai écris. Il y en a fort probablement, mais par
rapports à tous les problèmes, ils sont mineurs.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

Stéphane CARPENTIER

07/06/2020 à 00:57

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

Stéphane CARPENTIER , dans le message
, a écrit :
Là, on se répète. Effectivement par design, systemd n'est pas conçu pour
ordonnancer le démarrage.

En fait, si on y tient vraiment, on peut parfaitement décider l'ordre de
lancement des services avec systemd : il suffit de mettre des directives
Requires et After à tous les services.
Mais quel intérêt ?

Alors, pour tous les services, je ne veux surtout pas faire ça. J'ai
joué, étant jeune, à configurer le boot du DOS. Je ne sais plus comment
ça s'appelait mais comme quelqu'un avait décidé que 640ko c'était
largement suffisant pour tout le monde, pour certains trucs, il fallait
vraiment gérer l'ordre de chargement des drivers pour qu'ils puissent
tous être chargés. C'est rigolo au lycée ou à la fac de faire des
concours dessus. J'ai passé l'âge.
Pour certains services, comme je ne savais pas, c'est ce que j'ai fait.
Au moment de l'installation. Moi con, moi suivre doc. J'ai dit au ntp
de démarrer après le réseau. Comme ça marche comme ça et que c'est sans
risque : je garde. Mais si je me plonge dans systemd, c'est possible
que je remarque que c'est vraiment inutile et que je dégage. C'est pas
ma priorité.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

Yliur

07/06/2020 à 06:14

Le Sat, 06 Jun 2020 15:13:11 +0000, JKB a écrit :

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

Si un des reproches qu'on lui fait est qu'il s'occupe de trop de choses,
il y a des chances pour tous ces bugs ne concernent pas la partie
vraiment cruciale, sur laquelle tout repose.

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.

Je pense au contraire que la mémoire virtuelle ça inclut l'ensemble du
code du machin, c'est-à-dire que tout le code (ainsi que d'autres
fichiers ?) est associé à des adresses du processus. Mais que ce code
n'est chargé en mémoire (dans le cache système) qu'à la demande. Donc si
dans un cas particulier l'essentiel du code n'est pas utilisé, il
n'occupe pas de place en mémoire. Et s'il a été chargé en mémoire mais
qu'il ne sert plus (initialisation de la machine), les pages sont
candidates à dégager du cache système quand il y a besoin de place.
Ce qui peut expliquer pourquoi tout n'est pas verrouillé en mémoire : si
le processus sait faire beaucoup de choses mais qu'elles ne servent pas
souvent, mieux vaut ne pas tout maintenir en mémoire au cas où.
Les bibliothèques partagées c'était un autre chiffres, quelques Mo, que
je n'ai pas cité.

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.

Je ne comprends pas : soit ce cas n'arrive presque jamais, le code
correspondant n'est plus dans le cache système, il faut aller chercher
quelques pages sur le disque, ce n'est pas brillant mais ce n'est pas
forcément un désastre, soit ça arrive souvent et ce code se trouve
toujours dans le cache système (ou bien il y a de gros problèmes de
mémoire sur la machine ; et même dans ce cas je ne vois pas en quoi
privilégier le code de systemd qui sert à traiter la fin de vie des
processus est plus pertinent que laisser de la place pour autre chose en
mémoire).

Le Sat, 06 Jun 2020 15:13:11 +0000, JKB a écrit :

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

Si un des reproches qu'on lui fait est qu'il s'occupe de trop de choses,
il y a des chances pour tous ces bugs ne concernent pas la partie
vraiment cruciale, sur laquelle tout repose.

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.

Je pense au contraire que la mémoire virtuelle ça inclut l'ensemble du
code du machin, c'est-à-dire que tout le code (ainsi que d'autres
fichiers ?) est associé à des adresses du processus. Mais que ce code
n'est chargé en mémoire (dans le cache système) qu'à la demande. Donc si
dans un cas particulier l'essentiel du code n'est pas utilisé, il
n'occupe pas de place en mémoire. Et s'il a été chargé en mémoire mais
qu'il ne sert plus (initialisation de la machine), les pages sont
candidates à dégager du cache système quand il y a besoin de place.

Ce qui peut expliquer pourquoi tout n'est pas verrouillé en mémoire : si
le processus sait faire beaucoup de choses mais qu'elles ne servent pas
souvent, mieux vaut ne pas tout maintenir en mémoire au cas où.

Les bibliothèques partagées c'était un autre chiffres, quelques Mo, que
je n'ai pas cité.

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.

Je ne comprends pas : soit ce cas n'arrive presque jamais, le code
correspondant n'est plus dans le cache système, il faut aller chercher
quelques pages sur le disque, ce n'est pas brillant mais ce n'est pas
forcément un désastre, soit ça arrive souvent et ce code se trouve
toujours dans le cache système (ou bien il y a de gros problèmes de
mémoire sur la machine ; et même dans ce cas je ne vois pas en quoi
privilégier le code de systemd qui sert à traiter la fin de vie des
processus est plus pertinent que laisser de la place pour autre chose en
mémoire).

Vous avez filtré cet utilisateur ! Consultez son message

Le Sat, 06 Jun 2020 15:13:11 +0000, JKB a écrit :

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

Si un des reproches qu'on lui fait est qu'il s'occupe de trop de choses,
il y a des chances pour tous ces bugs ne concernent pas la partie
vraiment cruciale, sur laquelle tout repose.

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.

Je pense au contraire que la mémoire virtuelle ça inclut l'ensemble du
code du machin, c'est-à-dire que tout le code (ainsi que d'autres
fichiers ?) est associé à des adresses du processus. Mais que ce code
n'est chargé en mémoire (dans le cache système) qu'à la demande. Donc si
dans un cas particulier l'essentiel du code n'est pas utilisé, il
n'occupe pas de place en mémoire. Et s'il a été chargé en mémoire mais
qu'il ne sert plus (initialisation de la machine), les pages sont
candidates à dégager du cache système quand il y a besoin de place.
Ce qui peut expliquer pourquoi tout n'est pas verrouillé en mémoire : si
le processus sait faire beaucoup de choses mais qu'elles ne servent pas
souvent, mieux vaut ne pas tout maintenir en mémoire au cas où.
Les bibliothèques partagées c'était un autre chiffres, quelques Mo, que
je n'ai pas cité.

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.

Je ne comprends pas : soit ce cas n'arrive presque jamais, le code
correspondant n'est plus dans le cache système, il faut aller chercher
quelques pages sur le disque, ce n'est pas brillant mais ce n'est pas
forcément un désastre, soit ça arrive souvent et ce code se trouve
toujours dans le cache système (ou bien il y a de gros problèmes de
mémoire sur la machine ; et même dans ce cas je ne vois pas en quoi
privilégier le code de systemd qui sert à traiter la fin de vie des
processus est plus pertinent que laisser de la place pour autre chose en
mémoire).

Yliur

07/06/2020 à 06:54

Le Sat, 06 Jun 2020 19:27:46 +0000, JKB a écrit :

Tiens, dans les trucs complexes pas encore élucidé,
j'ai une réplication mariadb que systemd est infoutu de lancer
correctement parce qu'il y a un timeout qui traîne et que je n'ai
pas encore identifié. Systemd dans sa grande bonté lance tout en
même temps,
sauf que le master mariadb est sur un vpn à l'autre bout de la
France... Le temps d'établir le VPN, systemd tue mariadb sur le
slave parce qu'il considère qu'il n'a pas démarré assez vite.
Désopilant !

Mais le mariadb il vient à pied de l'autre bout de la France ?

Sauf qu'un merde de type systemd à récupérer sur 4000 caisses
enregistreuses Toshiba sur l'ensemble de la France, ça coule une
boîte un peu fragile. Mais il y a effectivement plein d'autres
raisons de planter une boîte.

Cet exemple semble bien loin de la PME qui a une machine unique avec une
configuration quelque part : ça ressemble à une situation dans laquelle
on a de quoi faire un test de migration et on ne fait pas des mises à
jour automatiques du système une fois que c'est validé, non ?

Redhat

10 réponses

Veuillez sélectionner un problème