Redhat

Yliur , dans le message <rbhru8$cei$2@dont-email.me>, a écrit :

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

Et surtout : il a pensé à déclarer « maridb doit venir après le VPN » ? Tout
simplement ?

Yliur , dans le message <rbhpi8$cei$1@dont-email.me>, a écrit :

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.

Exactement.

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

Les bibliothèques partagées sont simplement des fichiers mmapés, elles
comptent dans les 170 Mo, y compris les parties complètement inutilisées.

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

Là encore, exactement.

Le gestionnaire de mémoire de Linux est plutôt bon, il va garder en mémoire
les parties très utilisées automatiquement. C'est à croire que JKB n'a pas
remarqué que les systèmes d'exploitation ont progressé depuis les années
1980, et qu'il tient à pouvoir appliquer les stratégies de contournement
nécessaires à l'époque.

Stéphane CARPENTIER , dans le message
<slrnrdo7qc.qo.sc@scarpet42p.localdomain>, a écrit :

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.

Et c'est exactement ce qu'il faut faire : tu déclares ce qui est pertinent,
ce qui change les choses en pratique, NTP qui doit venir après le réseau, le
site web après la base de données, presque tout après le système de journal,
etc., et tu laisses systemd se débrouiller avec le reste, parce qu'au fond
tu te fiches de savoir si le démon bluetooth est lancé avant le serveur
d'impression.

C'est à croire que JKB administre ses machines au petit bonheur la chance :
« ah, machin démarre pas, je vais essayer de lancer truc plus tôt ».

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

Stéphane CARPENTIER , dans le message
<slrnrdo7qc.qo.sc@scarpet42p.localdomain>, a écrit :

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.

Et c'est exactement ce qu'il faut faire : tu déclares ce qui est
pertinent, ce qui change les choses en pratique, NTP qui doit venir
après le réseau, le site web après la base de données,

Chez moi j'ai plus de site web, mais au boulot, les sites web sont sur
des serveurs séparés des BDD. Donc le problème ne se pose pas de la même
façon. C'est ça que je n'arrive pas à comprendre avec JKB. D'un côté il
a une machine qui fait tout (et l'ordre du démarrage peut être
important, je le conçois) mais en même temps il a sa base de données qui
est à 1000 kilomètres de son serveur applicatif (mais alors si c'est sur
des serveurs différents on s'en cogne du démarrage par serveur, il
suffit de démarrer les serveurs dans l'ordre).

presque tout après le système de journal, etc.,

Sauf qu'il y a une grosse différence entre le réseau et le système de
journal. C'est que sur mon serveur de mail, si le réseau n'arrive
jamais, c'est catastrophique mais sur mon laptop, ça peut être normal.
Alors que le système de journal il arrivera forcément assez rapidement
(sauf incident critique).

Du coup, d'après ce que j'ai compris de systemd, si le système de
journal arrive en dernier, je m'en cogne car il arrivera quand même vite
et tout sera loggué rapidement, mes ressources libérées. Alors que si le
réseau n'arrive jamais, si ntp démarre, il va balancer plein de trucs au
réseau, qui seront mises en caches et jamais libérées puisque le réseau
n'arrivera jamais. Il y a donc, potentiellement, un risque de saturation
des ressources à cause d'une accumulation de ce qui est mis en cache.
Mais pour ça, il faut que je me plonge dedans pour savoir si le risque
est potentiel ou réel. Mon but de dire à ntp de démarrer après le réseau
est plus de lui dire de ne pas démarrer si c'est inutile que de lui
éviter de démarrer trop vite.

et tu laisses systemd se débrouiller avec le reste, parce qu'au fond
tu te fiches de savoir si le démon bluetooth est lancé avant le serveur
d'impression.

Oui, mais puisque mon système est bien dimensionné, si j'ai bien tout
compris, je me fiche aussi de savoir si le bluetooth démarre avant le
système de log ou pas. Si j'ai quitté Ubuntu c'est parce que j'avais
perdu le contrôle du bousin. Mais ce qui me posait problème, c'est de
savoir ce qui est lancé pas de savoir dans quel ordre c'est lancé.

C'est à croire que JKB administre ses machines au petit bonheur la
chance : « ah, machin démarre pas, je vais essayer de lancer truc plus
tôt ».

Ce qui me surprend, c'est qu'il a l'air de trouver que tous les
problèmes peuvent être résolus par l'ordre du lancement des process.
Quand tu me sors que je connais moins bien le monde de la recherche que
toi, je l'accepte, j'ai été à la fac il y a longtemps et je lis des
trucs, mais c'est pas de première main. Quand il me sort que je connais
moins bien le monde de la PME que lui, je l'accepte aussi, j'ai été
dedans il y a longtemps et je n'y suis pas resté longtemps, j'ai donc
une vision limitée.

Par contre, le monde de la grosse entreprise, je connais. Je veux bien
qu'un serveur dédié lance moins de services qu'un serveur unique qui
fait tout. Mais le routage d'une grosse entreprise, c'est autrement plus
complexe que le routage d'une PME. On parle de milliers de serveurs qui
doivent tous interagir entre eux (ou pas, il y a aussi des restrictions
à gérer qui complexifient tout). Et je ne te parle pas des milliers
d'utilisateurs. Le réseau est un peu pourris, soit, mais vu les
conditions, ils s'en tirent pas si mal.

Donc, si à chaque reboot c'était la guerre parce que systemd renommait
systématiquement toutes les interfaces sans que ce soit prédictible, je
le saurais. Je ne sais pas si c'est parce qu'ils sont super balèzes et
qu'ils ont corrigés tous les problèmes de systemd ou parce que systemd
est moins aléatoire que ce qu'indique JKB. Mais ce que je sais, c'est
que ça marche globalement et les problèmes remontés sont ailleurs.

Le mec derrière le bouton reset pour appuyer en cas d'échec alors que la
majorité des reboots est automatique est ridicule. Le serveur de test
identique au serveur de prod qui permet de tout prévoir alors que quand
on passe du test à la prod on change d'écosystème est aussi ridicule.

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

Le 07/06/2020 à 12:49, Nicolas George a écrit :

Le gestionnaire de mémoire de Linux est plutôt bon

Au royaume des aveugles les borgnes sont rois.

--
Michel Talon

Stéphane CARPENTIER , dans le message
<slrnrdpnvq.qt.sc@scarpet42p.localdomain>, a écrit :

C'est ça que je n'arrive pas à comprendre avec JKB.

Ça fait un certain temps que je me demande si l'explication n'est pas à
trouver dans un dictionnaire entre mythologie et myxine.

Sauf qu'il y a une grosse différence entre le réseau et le système de
journal. C'est que sur mon serveur de mail, si le réseau n'arrive
jamais, c'est catastrophique mais sur mon laptop, ça peut être normal.
Alors que le système de journal il arrivera forcément assez rapidement
(sauf incident critique).

Du coup, d'après ce que j'ai compris de systemd, si le système de
journal arrive en dernier, je m'en cogne car il arrivera quand même vite
et tout sera loggué rapidement, mes ressources libérées.

Non, non, non ! Il faut que le système de journal arrive en premier parce
que sinon, si quelque chose ne marche pas tu ne saurais pas pourquoi.

Alors que si le
réseau n'arrive jamais, si ntp démarre, il va balancer plein de trucs au
réseau, qui seront mises en caches et jamais libérées puisque le réseau
n'arrivera jamais. Il y a donc, potentiellement, un risque de saturation
des ressources à cause d'une accumulation de ce qui est mis en cache.

Là, tu te fais des noeuds au cerveau pour rien. Si ntp est lancé avant le
réseau, il va juste essayer d'envoyer et pas réussir. Il n'y a aucun cache
dans l'histoire ni risque de saturation.

Mais pour ça, il faut que je me plonge dedans pour savoir si le risque
est potentiel ou réel. Mon but de dire à ntp de démarrer après le réseau
est plus de lui dire de ne pas démarrer si c'est inutile que de lui
éviter de démarrer trop vite.

Oui. C'est pour ça que systemd a trop de manière d'écrire des dépendances :
Requires, After, Wants, etc.

Oui, mais puisque mon système est bien dimensionné, si j'ai bien tout
compris, je me fiche aussi de savoir si le bluetooth démarre avant le
système de log ou pas.

Non, le système de log doit venir avant sinon le bluetooth ne peut pas
loguer ses problèmes.

Donc, si à chaque reboot c'était la guerre parce que systemd renommait
systématiquement toutes les interfaces sans que ce soit prédictible

Ah, le coup des noms des interfaces réseau, c'est encore une spectaculaire
explosion de mauvaise foi.

La réalité est exactement le contraire de ce que te racontent les
systemdphobes.

Avec le matériel moderne, très asynchrone, il est possible qu'une carte
réseau s'initialise en un peu plus de temps un jour, donc il est possible,
pour une machine qui en a plusieurs, que lors d'un boot elles se retrouvent
dans le désordre.

Il y avait des solutions, typiquement une règle udev qui fixe le nom en
fonction de l'adresse MAC. Mais pour être fiable, il faut que
l'administrateur le fasse.

À un moment, systemd a décidé de régler le problème différemment, en donnant
à toutes les interfaces un nom unique, dérivé de son branchement. Donc au
moment de cette mise à jour, toutes les interfaces ont changé de nom,
évidemment, et pour un nom moins pratique. Mais c'était justement pour
garantir que le nom soit parfaitement constant

Et bien sûr, c'est une fonctionnalité optionnelle, et les anciennes
techniques fonctionnent encore.

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

Stéphane CARPENTIER , dans le message
<slrnrdpnvq.qt.sc@scarpet42p.localdomain>, a écrit :

Du coup, d'après ce que j'ai compris de systemd, si le système de
journal arrive en dernier, je m'en cogne car il arrivera quand même
vite et tout sera loggué rapidement, mes ressources libérées.

Non, non, non ! Il faut que le système de journal arrive en premier
parce que sinon, si quelque chose ne marche pas tu ne saurais pas
pourquoi.

OK, ça a dû être configuré comme ça, je n'ai pas l'intention de modifier
pour voir.

Mais pour ça, il faut que je me plonge dedans pour savoir si le
risque est potentiel ou réel. Mon but de dire à ntp de démarrer après
le réseau est plus de lui dire de ne pas démarrer si c'est inutile
que de lui éviter de démarrer trop vite.

Oui. C'est pour ça que systemd a trop de manière d'écrire des
dépendances : Requires, After, Wants, etc.

OK, je verrai ça le jour où je me plongerai dedans.

Donc, si à chaque reboot c'était la guerre parce que systemd
renommait systématiquement toutes les interfaces sans que ce soit
prédictible

Ah, le coup des noms des interfaces réseau, c'est encore une
spectaculaire explosion de mauvaise foi.

Oui, mais c'est autorisé ici. Après, je ne suis pas obligé d'y croire.

Avec le matériel moderne, très asynchrone, il est possible qu'une
carte réseau s'initialise en un peu plus de temps un jour, donc il est
possible, pour une machine qui en a plusieurs, que lors d'un boot
elles se retrouvent dans le désordre.

Jusque là, je le savais.

Il y avait des solutions, typiquement une règle udev qui fixe le nom en
fonction de l'adresse MAC. Mais pour être fiable, il faut que
l'administrateur le fasse.

Avant le « Mais » je le savais, ce qui est après m'avait échappé. Je ne
comprenais pas pourquoi c'était pas basé dessus alors que dans la doc ça
semblait être le mieux. Dans la doc, il me semblait que ça pouvait aussi
se baser sur le nom donné par le fabriquant.

À un moment, systemd a décidé de régler le problème différemment, en
donnant à toutes les interfaces un nom unique, dérivé de son
branchement.

Oui, c'est comme ça chez moi. Sans que je ne fasse rien, c'est ce qui
est dans la doc (par défaut si c'est pas sur MAC, c'est indiqué que ça
se base dessus). C'est prédictible et c'est toujours pareil à chaque
reboot.

Donc au moment de cette mise à jour, toutes les interfaces ont changé
de nom, évidemment,

Ah, OK. Ça, je ne le savais pas et ça explique beaucoup de choses.

et pour un nom moins pratique. Mais c'était justement pour garantir
que le nom soit parfaitement constant

Moins pratique c'est une façon de voir. C'est plus long, c'est clair.
Sans comprendre la construction, ça fait peur et c'est moins parlant,
c'est clair. Mais ça donne une certaine homogénéité sur tout ce qui est
branché, pas que les prises réseau. Et ça permet de faire facilement le
lien entre « lspci » et « ip addr » ou encore le lien entre « lspci » et
« lsblk » par exemple. Et ça, quand on cherche son matériel, ça peut
être d'un grand secours.

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

Le Sun, 07 Jun 2020 15:00:46 +0200, Michel Talon a écrit :

Le 07/06/2020 à 12:49, Nicolas George a écrit :

Le gestionnaire de mémoire de Linux est plutôt bon

Au royaume des aveugles les borgnes sont rois.

Parce que tu penses qu'il en existe de bien meilleurs ou simplement parce
qu'il reste toujours des cas où le système ne prend pas les bonnes
décisions ?

Stéphane CARPENTIER , dans le message
<slrnrdq2cp.qt.sc@scarpet42p.localdomain>, a écrit :

Avant le « Mais » je le savais, ce qui est après m'avait échappé. Je ne
comprenais pas pourquoi c'était pas basé dessus alors que dans la doc ça
semblait être le mieux. Dans la doc, il me semblait que ça pouvait aussi
se baser sur le nom donné par le fabriquant.

Tu ne veux pas apprendre par coeur les 48 bits de ton adresse MAC, même si
en réalité c'est un peu moins que 48. Donc la correspondance adresse MAC
vers nom d'interface réseau ne peut pas être algorithmique, on ne peut pas
juste le calculer. Mais du coup, ça veut dire que le même nom court va
servir pour ta carte celle du voisin.

Il faut donc quelque chose qui enregistre la liste des cartes réseau qui
sont à toi, et leur associe l'identifiant court. Il y a eu des velléités
d'avoir une règle udev, persistent-net-generator.rules, qui détecte les
interfaces réseau encore inconnue et les écrive dans une règle udev. Mais le
résultat n'était pas très robuste.

Mais une règle explicite avec l'adresse MAC, ajoutée manuellement, ça marche
toujours très bien :

ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*",
ATTR{address}=="9d:78:94:f8:5e:d2", NAME="eth0"
ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*",
ATTR{address}=="ca:cf:45:15:a0:5e", NAME="eth1"

Ah, OK. Ça, je ne le savais pas et ça explique beaucoup de choses.

Le changement avait été clairement annoncé, quand même.

Moins pratique c'est une façon de voir. C'est plus long, c'est clair.
Sans comprendre la construction, ça fait peur et c'est moins parlant,
c'est clair. Mais ça donne une certaine homogénéité sur tout ce qui est
branché, pas que les prises réseau. Et ça permet de faire facilement le
lien entre « lspci » et « ip addr » ou encore le lien entre « lspci » et
« lsblk » par exemple. Et ça, quand on cherche son matériel, ça peut
être d'un grand secours.

Oh, je suis d'accord avec tout ça. Mais le nouveau schéma est moins pratique
*à taper* : plus de chiffres à apprendre, une alternance de lettres et de
chiffres plutôt qu'un presque mot. C'est pourquoi, sur mes machines, je
préfère utiliser une règle udev.

Le 06/06/2020 à 21:27, JKB a écrit :

Fin de la discussion.

Merci pour toutes tes explications techniques sur ce système init à la
mode Windows.


--
jp willm
http://willms.yj.fr/willms/index.html