udev-init-scripts-33 + openrc en parrallèle = désastre !

[zelurker]

Jusqu'ici j'utilisais sys-fs/udev + openrc avec
rc_parrallel="YES" dans /etc/rc.conf et tout marchait très bien. (et sans systemd évidemment puisqu'openrc).

Hier soir, upgrade vers udev-init-scripts-33, je ne me suis pas méfié tout avait l'air d'aller bien.
Ce matin, boom, foirage complet du boot, on se retrouve en console, / toujours monté en ro (donc aucun log utilisable !), clavier anglais, en gros presque tous les trucs habituellement lancés par openrc n'ont pas été lancés... !
Après quelques tests, remettre
rc_parrallel="NO" dans /etc/rc.conf résoud le problème, mais le boot est + lent évidemment.
Il n'y a pourtant pas beaucoup de changements dans ces udev-init-scripts, apparemment c'est surtout l'option --daemon qui disparait des arguments par défaut d'udevd (ou /lib/systemd/systemd-udevd). J'ai essayé de le remettre en modifiant /etc/conf.d/udev, ça ne change absolument rien, ça marche avec ou sans, sans rien changer au problème, impossible de lancer openrc en parrallèle maintenant... !

Je me demande si je n'aurais pas du utiliser eudev à la place de sys-fs/udev ?
Le truc c'est qu'il refuse de me laisser remplacer l'un par l'autre maintenant :
sys-fs/udev ("sys-fs/udev" is blocking sys-fs/eudev-3.2.5)
Et bon forcer la désinstallation de udev avec emerge -Cv sur un système qui tourne n'est pas forcément une bonne idée, surtout que si ça se trouve ça ne marchera pas mieux...
Donc pour l'instant je reste avec rc_parallel=NO, mais si quelqu'un a des idées, je suis preneur !

Je pourrais aussi downgrader udev-init-scripts pour voir...

[Syl20]

D'expérience, vouloir absolument démarrer tous les services en même temps, dans l'espoir de gagner quelques secondes, c'est une mauvaise économie (on le paie en heures de debug...). Sans même parler de systemd, qui, en plus, le fait très mal...
Mais bon, si tu es vraiment pressé, oui, vire udev et installe eudev. C'est plus stable.

Tu peux le faire en mode "même-pô-peur", ça fait plusieurs années que ça marche. Il faut juste éviter de redémarrer la bécane entre la désinstallation de udev et l'installation complète de eudev, évidemment.
Au pire, si tu as vraiment besoin de "ceinture et bretelles", fais une sauvegarde de ton système juste avant la manip, ça t'évitera d'avoir à ressortir celle d'hier (tu as bien une sauvegarde d'hier, n'est-ce pas ?).

[El_Goretto]

+1
Oui, il doit traîner des guides Gentoo pour utiliser une alternative à ce composant, car je me revois basculer plusieurs machines vers mdev sans même souiller mon slip.
_________________
-TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT)

[zelurker]

Bah dans ma conf le démarrage parallèle est vraiment pratique, j'ai collé un peu trop de trucs à configurer au niveau du réseau qui fait un sacré point de ralentissement du coup et c'est agréable d'avoir le reste qui s'init quand même, on sent vraiment la différence.

J'ai été voir dans le metadata du package, pour le mail du mainteneur ils mettent udev-bugs@gentoo.org, ça a l'air tout à fait dédié à ce genre de problème, j'ai envoyé un message, j'ai eu une réponse, il dit qu'il ne devrait pas y avoir de différence avec eudev et qu'à priori il vaut mieux garder udev, après il m'a fait douter avec l'upgrade de kmod que j'ai fait en même temps du coup j'ai downgradé uniquement udev-init-scripts, remis rc_parallel, et je confirme, ça remarche !
Donc on attend la suite, on verra bien...
ça fait peur quand même ce genre de truc, on a plus l'habitude de se retrouver dans un système aussi cassé de nos jours ! en + monter un système de fichier autre que / provoquait une déconnexion de la session, le genre vraiment très mal parti ! Enfin, ça va mieux pour l'instant !!!

[zelurker]

Finalement j'ai du enquêter un peu + là-dessus vu que ça n'arrivait que chez moi, ce qui fut délicat vu que ça allait trop vite pour voir ce qui arrivait, l'écran s'effaçait et on se retrouvait sur l'écran de login et sans logs.
J'ai appris à connaitre l'option -J de agetty pour ne pas effacer l'écran avant d'afficher le login !
Et finalement c'était un module qui faisait une assertion failure sur la création d'un thread, vboxdrv de virtualbox !
Alors pourquoi il fait ça quand rc_parallel="YES" et seulement avec le nouveau fichier init, c'est une bonne question, et peut-être que j'enquêterai là-dessus + tard, mais pour l'instant j'avais le choix entre virer virtualbox ou remettre rc_parallel="NO", ce que j'ai fait, c'était + facile !

Fin du problème, donc, désolé pour les posts un peu longs, enfin j'en ai appris sur ce coup là !

[Syl20]

Race condition
Il suffit que certains des scripts mis à jour mettent un chouia plus ou moins de temps à s'exécuter, pour diverses raisons (types d'appels système, nombre d'instructions, etc.), et ça tombe en marche. Ou pas.
Et donc, si ça fonctionnait chez toi jusque-là, c'était juste... un coup de bol. Rassurant, hein ?

[zelurker]

Bah après une recherche de quelques jours sur le sujet parce que j'ai soupçonné une défaillance matérielle alors j'ai préféré me rassurer, il semblerait que quelque chose lié à udev bloque la création de threads pendant un temps très court qui normalement passe inaperçu, sauf si évidemment on est en démarrage parallèle à ce moment là !
Alors je ne suis pas capable de dire ce qui bloque les threads exactement, je n'ai pas de règle bizarre dans udev, je peux quand même dire que si on passe --daemon à udev, ce qui était le cas dans udev-init-scripts-32, dans ce cas là il ne forke pas dès le lancement, il fait un paquet d'inits avant de le faire, j'ai pas été vérifier si il lit pas ses règles avant le fork mais ça ne m'étonnerait pas. En tous cas ça fait que tous les scripts d'openrc qui dépendent d'udev sont donc en attente du fork à ce moment là, et quand finalement ça arrive, c'est bon, les threads passent et y a pas de problème.
La version 33 a retiré le --daemon, c'est ça qui a foutu la merde, mais chez moi uniquement, ça doit dépendre de la vitesse à laquelle les scripts démarrent après udev, là c'est un ssd + un ryzen 8 cores + 8 smt, donc 16 cpus virtuels, visiblement ça va vite. Et donc les 2 solutions c'est démarrage séquentiel, ce que j'ai fait pendant un moment, mais avec tous mes scripts réseau à démarrer je rongeais un peu mon frein, ou remettre le --daemon à udev, et là on peut repasser en démarrage parallèle sans problème, ce que je fais en ce moment. Je gagne 50% de temps de démarrage en gros, je me suis amusé à ajouter une notification qui apparait sur le bureau quand l'init réseau est terminée, elle arrive entre 12 et 13s après la fin du boot normal où j'ai la main sur le bureau graphique !
Bon, ok, j'avoue je pourrais aussi choisir le démarrage lent séquentiel, 13s c'est pas la mort, mais c'est amusant à voir un démarrage pareil !

Enfin voilà, fin du problème, parenthèse close, je ne sais pas ce qu'ils vont faire au niveau d'udev-init-scripts, mais comme je sais comment gérer ça c'est pas grave.

[Syl20]

Fin du problème ? Pas tout-à-fait. Tu pourrais ajouter des précisions dans le rapport de bug dédié : https://bugs.gentoo.org/678638
Si possible en citant le commit correspondant : https://gitweb.gentoo.org/proj/udev-gentoo-scripts.git/commit/?id=6f98cf89f54a9ad1c9625577d100f6ca8b8a2b0b

[zelurker]

Ok, merci pour les liens, je n'aime pas trop créer des bug reports, mais là y a juste à ajouter un post donc je peux quand même faire ça !