PROJET AUTOBLOG


Blog-Libre

Site original : Blog-Libre

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

Résoudre les lenteurs au démarrage de Ubuntu-Mint

mercredi 15 août 2018 à 09:45

J’appelle problème bloquant, un problème m’empêchant d’utiliser un outil. Cela ne signifie pas obligatoirement “l’outil ne fonctionne pas” mais plus globalement “l’outil n’est pas utilisable pour moi en l’état“. C’est le cas ici, je teste Mint XFCE et j’ai un démarrage en 46 secondes. Le démarrage fonctionne mais le temps de démarrage est bloquant pour moi, hors de question de rester sur une distrib qui met autant de temps à démarrer. Je suis en dual-boot, Xubuntu démarre en 7s.

Identifier

Il est nécessaire de connaître deux commandes pour identifier les lenteurs au démarrage des systèmes d’exploitation utilisant systemd : systemd-analyze et systemd-analyze blame. Vous en croiserez parfois une troisième permettant de présenter les résultats de manière graphique : systemd-analyze plot (à utiliser ainsi systemd-analyze plot > boot.svg). Un man systemd-analyze vous renseignera sur la fonction de chacune.

Voici le résultat de systemd-analyze sur ma Mint XFCE. Le noyau Linux (kernel) met donc 35s au démarrage et l’espace utilisateur (userspace) 11s. C’est ce résultat que je désigne par “démarrage” dans cet article et pour être précis tiré du man : “the time spent in the kernel before userspace has been reached, the time spent in the initial RAM disk (initrd) before normal system userspace has been reached, and the time normal system userspace took to initialize”. On vient d’identifier deux problèmes, lenteur au niveau kernel et lenteur au niveau userspace.

Startup finished in 35.072s (kernel) + 11.461s (userspace) = 46.533sgraphical.target reached after 1.380s in userspace

Un systemd-analyze blame affiche le temps d’initialisation de chaque service et donne le résultat suivant (tronqué aux 5 premiers résultats). On identifie de suite la raison de la lenteur au démarrage de l’userspace : ntp.service. Ce service met 10s à s’initialiser à lui tout seul.

10.153s ntp.service408ms dev-nvme0n1p3.device292ms NetworkManager.service252ms systemd-cryptsetup@cryptswap1.service245ms systemd-resolved.service

Je vous invite à tester en live ces commandes sur votre pc. L’immense majorité des services systemd démarrent en moins d’une seconde si vous avez un SSD. Évidemment certains services sont lourds/longs à démarrer : virtualisation, bases de données… Je simplifie mais tout service qui démarre en plus de 2-3 secondes mérite votre attention : Est-il nécessaire ? À quoi sert-il ? Pourquoi ce délai ?

Diagnostiquer

On commence à mettre les mains dedans : Qu’est-ce qui provoque ce délai et est-ce qu’une action change ce délai ? Commençons par le service ntp.

La bonne manière de procéder : 1/ Favoriser des tests aux résultats visibles et compréhensibles, ça oriente et confirme nos soupçons. On doit être sûr que c’est notre action qui a changé quelque chose, pouvoir constater un changement, comprendre ce qu’on a fait et ce qui s’est passé 2/ Effectuer des tests qui impactent le moins possible le système d’exploitation afin de pouvoir revenir en arrière (rollback) et reproduire la situation d’origine 3/ Pour rechercher et isoler la cause d’un problème, on va du grossier au précis. Plutôt que faire 100 tests sur des choses précises (plus long et difficile), il vaut mieux faire un test général pour savoir dans quelle direction poursuivre (disque, kernel, réseau, etc.) 4/ Créer des tests de sorte que problème/résultat soient reproductibles ainsi on teste et valide facilement/rapidement une action

Ici nous allons donc simplement désactiver le service ntp sudo systemctl disable ntp.service (pour rollback : sudo systemctl enable ntp.service), redémarrer sudo reboot puis afficher de nouveau le résultat systemd-analyze blame. Il est évident mais ça confirme qu’il n’y a pas d’effets indésirables dans l’immédiat : L’userspace démarre en moins de 2 secondes. On gagne près de 10s à chaque démarrage.

Repassons sur notre lenteur kernel. Lorsqu’on arrive sur Grub, on choisit Advanced options for Linux Mint 19 Xfce puis Linux Mint 19 XFCE (recovery mode) et on regarde ce qui se passe. Dans mon cas c’est simple, ça reste longtemps sur un message : Scanning for btrfs file systems. On va orienter nos recherches de ce côté-là.

Réparer

Le service ntp permet de fournir l’heure exacte au système d’exploitation, on ne peut pas se contenter de le laisser désactivé mais on peut probablement lui trouver un remplaçant. Je vous recommande chaudement chrony, vous pouvez aussi passer à systemd-timesyncd. Chrony est méconnu pourtant c’est la nouvelle référence, il est déjà utilisé de base sur les systèmes Fedora, CentOS, Red Hat. Sa configuration par défaut est sécurisée, correcte, il n’écoute qu’en local et n’agit qu’en client NTP. Il faut donc juste l’installer : sudo apt install chrony. On redémarre sudo reboot puis on affiche de nouveau le résultat systemd-analyze blame : La lenteur constatée niveau userspace a disparu, on a définitivement gagné 10s à chaque démarrage, le service chrony s’initialise en 54ms. On aurait pu creuser le problème du service NTP, ça aurait pris sûrement beaucoup plus de temps. Nous avons là une solution simple, rapide, satisfaisante.

En effectuant quelques recherches sur la lenteur niveau kernel, on apprend qu’il y a des problèmes avec le noyau 4.15.0-20. On vérifie notre noyau (uname -r), pas le même. Le plus évident lorsqu’on a un problème avec un noyau, c’est d’en tester un autre.

On se rend sur http://kernel.ubuntu.com/~kernel-ppa/mainline/ puis on cherche la dernière branche. Le plus simple étant de cliquer sur Last modified, actuellement le noyau le plus récent est le 4.18. Je n’aime pas prendre la dernière version, je lui préfère une version antérieure (par exemple la 4.17.12) : 1/ Les bugs commencent à être connus et identifiés, on peut retrouver leurs traces 2/ Trop récent, peu fiable.

On télécharge, on installe, on redémarre, on vérifie le noyau et systemd-analyze.

wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.12/linux-headers-4.17.12-041712-generic_4.17.12-041712.201808030231_amd64.deb http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.12/linux-headers-4.17.12-041712_4.17.12-041712.201808030231_all.deb http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.12/linux-image-unsigned-4.17.12-041712-generic_4.17.12-041712.201808030231_amd64.deb http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.12/linux-modules-4.17.12-041712-generic_4.17.12-041712.201808030231_amd64.debsudo dpkg -i linux*4.17.12*.debsudo rebootuname -rsystemd-analyze

Pas de bol, pas mieux ! On a encore un démarrage kernel de plus de 30 secondes. À noter que sur Grub, on peut toujours choisir de booter sur l’ancien noyau. On va faire des recherches sur Scanning for btrfs file systems, je précise que je n’utilise pas btrfs sur mon pc.

Le premier lien est la solution qui a marché pour moi.

sudo blkid # On affiche les identifiants (UUID) des périphériques bloc (systèmes de fichiers)sudo cat /etc/initramfs-tools/conf.d/resume # On compare les UUID de la commande blkid avec le contenu du fichier resume, dans mon cas aucune correspondance. L'UUID ne correspond à aucun périphérique bloc, c'est incohérentsudo cp /etc/initramfs-tools/conf.d/resume ~/resume.bak # On fait une sauvegarde du fichier pour pouvoir rollbacksudo nano /etc/initramfs-tools/conf.d/resume # Remplacer RESUME=UUID=xxx par RESUME=nonesudo update-initramfs -u

Je pense qu’une bonne explication est ici. Je recommande également ces liens connexes : 1, 2, 3, 4. Pour résumer il y a des problèmes si vous chiffrez votre /home notamment autour de la swap. Dans la release notes de Mint 19 XFCE, Known issues : There is an issue with home directory encryption that causes swap to be misconfigured during installation. To correct this…”

Conclusion

Au début de l’aventure.

Startup finished in 35.072s (kernel) + 11.461s (userspace) = 46.533sgraphical.target reached after 1.380s in userspace

Après la résolution du problème dans l’userspace (ntp.service).

Startup finished in 35.071s (kernel) + 1.371s (userspace) = 36.442sgraphical.target reached after 1.363s in userspace

À la fin de l’aventure (après la résolution du problème niveau kernel).

Startup finished in 3.786s (kernel) + 1.380s (userspace) = 5.167sgraphical.target reached after 1.373s in userspace

Je démarre à présent en moins de 6s, 40s gagnées à chaque démarrage, un confort indéniable. Soulignons le fait qu’une version LTS (Long Term Support) n’est pas exempte de soucis/bugs, que le démarrage est aussi concerné par des problèmes/optimisations.

J’ai essayé de vous fournir une méthodologie et quelques bases pour vous débrouiller avec des lenteurs au démarrage, l’article Danse avec les reboots est un bon complément. Les commentaires sont ouverts, je réponds aux questions.

Tcho !

Mint XFCE… ou pas

dimanche 12 août 2018 à 10:30

Je suis en train de tester Mint XFCE. Dans l’article Xubuntu 18.04… ou pas je soulignais les points qui me posent dorénavant problème avec Ubuntu : Télémétrie et paquets snap.

Mint a décidé de ne pas inclure le paquet ubuntu-report de télémétrie (Ubuntu ships with “ubuntu-report”, which collects metrics and usage data. This package won’t be present in Linux Mint, no data will be collected or sent) et a choisi Flatpak. J’ai envie d’ajouter la vie est bien faite ha ha ha.

J’aime beaucoup leur communication, un billet mensuel (Monthly News) ainsi que des billets annonçant les sorties (avec release notes). J’y vois une vraie attention pour informer l’utilisateur de ce qu’il se passe notamment les problèmes (Known issues). Dans le billet mensuel on trouve une liste de donations reçues par mois avec une moyenne de 10000 dollars sur les trois derniers mois. Non seulement il s’agit d’une grosse somme mais certains donateurs donnent de manière répétée et importante. Ci-dessous une liste tronquée jusqu’à $40. Ça signifie beaucoup pour moi, les utilisateurs soutiennent et récompensent le boulot effectué, c’est très positif.

$304 (2nd donation), B. Nikola aka “Germmare”
$300, Maciej F.
$272, Christian F.
$250, Wendy J.
$145 (17th donation), Jon Espenschied aka “xeno”
$125, Timothy D.
$109 (3rd donation), Heinz G.
$109, Néstor A. S.
$109, Jürgen S.
$100 (3rd donation), Mirza B.
$100 (2nd donation), Martin G.
$100 (2nd donation), Ray W. aka “Ambiray”
$100 (2nd donation), H. J. M.
$100, Len W.
$100, Peter P.
$100, Paul R.
$100, Minjun Y.
$100, Todd H.
$100, David B.
$100, Yasser T.
$100, Erik J.
$100, Craig V. V.
$97, Willian B. D. S.
$87 (2nd donation), Alfred B.
$65 (4th donation), Ion L. I.
$54 (13th donation), Dr. R. M.
$54 (4th donation), Dirk B.
$54, Juan Valencia Calvellido aka “calvellido”
$54, Stephan Tietz
$54, Jan H.
$54, Volkan C.
$54, Lasse L.
$54, Pierre E.
$54, Champeau C.
$54, David P.
$54, Anthony W.
$54, Jörg G.
$50 (8th donation), Thomas T. aka “FullTimer1489”
$50 (3rd donation), Stephen T.
$50 (3rd donation), Michael K.
$50 (2nd donation), Tony C.
$50 (2nd donation), Timmn
$50 (2nd donation), Dallas H.
$50 (2nd donation), Programmed Precision
$50 (2nd donation), Peter P.
$50 (2nd donation), Brian S.
$50, Savvas H.
$50, ScreenType GmbH
$50, Scott M.
$50, Rod S.
$50, Walter S.
$50, Tim K.
$50, Joseph G.
$50, Barton H.
$50, aka “siggjen”
$50, Bryce P.
$44 (2nd donation), Peter D.
$44 (2nd donation), Sylvain D.
$44, Karl H.
$44, Antonín S.
$44, Philippe R.
$40 (3rd donation), M. B. .
$40, Jason F.
$40, Dimitrios G.
$40, Dean M.
$40, Bruno K.

A l’heure actuelle j’ai essuyé les premiers plâtres dessus (billet en approche), pas simple mais c’est réglé. Je n’ai plus de soucis bloquants et je préfère déjà booter sur Mint que sur Xubuntu. On verra ce que ça va donner en utilisation continue mais pour l’instant : +1 !

Dans un ancien article Les nouveaux usages, je parlais du changement. Il est difficile de voir et savoir quand quelque chose change, il faut s’informer. Mint déjà meilleure que Ubuntu ? Je la trouve rapide, soignée avec de bonnes idées pour les utilisateurs (Update Manager, paquets Flatpak mis à jour automatiquement, Timeshift pour rollback en cas de pb) et une différence de plus en plus marquée avec Ubuntu (Télémétrie, paquets snap…). Encore plus difficile la résistance au changement, les habitudes ancrées, le confort du connu, la peur de l’inconnu.

Pour info je procède au partitionnement suivant sur mon poste (SSD 256 Go) :

Je rappelle que je me sers de mon poste à titre professionnel donc 1/ Je bosse avec 2/ Ça doit fonctionner 3/ Mais il faut que je puisse switcher vers une nouvelle distrib si je le désire (sans quoi la réinstallation m’empêche de bosser). Bref cette petite organisation m’apporte souplesse et capacité de tester/basculer.

Marche ou crève

dimanche 5 août 2018 à 06:15

Il y a une certaine honte à parler de burn-out (ou de bore-out), une chape de plomb. Pour certains ça revient à avouer une faute, une faille en soi. On est honteux de cela, on n’a pas été à la hauteur. J’ai vu des gens très intelligents trébucher, tomber. Zythom en a très bien parlé, Genma est en plein dedans, Jérôme Petazzoni a fait un récap. J’aime beaucoup la conclusion de Zythom : “Je ne suis ni un héros, ni un zéro. Je fais de mon mieux. Et parfois, ce n’est pas terrible”.

Je ressens une grosse fatigue que je traîne depuis 2 ans maintenant et que j’ai décidé d’assumer.

Ça a commencé avec la naissance de mon fils, ce qui devait être une fête a été un évènement manqué. Je comptais sur mon congé de paternité (11 jours calendaires), tout était prévu. Malheureusement mon supérieur de l’époque est parti en burn-out alors qu’on était dans une grosse période au boulot. Niveau technique (serveurs, postes de travail, demandes des utilisateurs) il ne restait donc que moi… La DRH m’a dit : “À vous de voir, on ne vous le reprochera pas”. Je ne me voyais pas laisser le service et l’entreprise dans la merde pendant 2 semaines… boulot boulot. J’ai pris mes 11 jours calendaires deux mois plus tard mais c’était pas pareil. Certaines blessures restent coincées au fond de la gorge. J’ai fait un choix, la vie m’a forcé à en faire un, pas de bol. Je ne me voyais pas laisser tomber le service, l’entreprise et que mon chef paye l’addition. Je ne lui en veux pas du tout, ça arrive, personne n’est invincible.

Je me souviens clairement avoir identifié que j’étais heureux fin 2016. Je crois que chaque individu a une définition différente du bonheur, pour moi c’est un ciel bleu, aucun problème à l’horizon, tout va bien, tous les proches vont bien. Pour résumer l’absence totale de soucis. Quand on devient parent, une chose colossale change, on a d’un coup beaucoup plus de responsabilités. Je dépérissais au boulot, je m’ennuyais mais j’étais incapable de prendre la décision de perdre tout le confort de ce job pour aller risquer d’en trouver un autre où je m’épanouirai. Mes parents ainsi que Madame étaient contre le fait que je parte, j’avais tous les avantages qu’on puisse avoir. Pourtant moi ça n’allait pas, être et avoir.

J’ai passé quelques jours avec A1. Il m’a tendu un miroir, nos échanges ont résonné en moi, appuyé sur ce qui n’allait pas. J’ai pris la décision de quitter mon ancien job, je n’ai pas de regrets aujourd’hui (enfin si les deux jours de RTT par mois ha ha ha). C’était un nouveau départ, passer de sysadmin Windows à sysadmin Linux. Je me suis mis la pression parce que ne pas suivre les remarques des proches est une chose mais il faut assumer et assurer derrière. J’ai assumé et assuré mais je suis à genoux. Fatigué, épuisé.

Je ressens une accumulation, une dette envers moi-même de choses que j’aurais voulu faire, que j’aurais dû faire.

La seule solution est de prendre soin de soi, prendre le temps, prendre son temps. Mais comment ? Lever le pied signifie ne plus avoir un salaire complet donc des soucis d’argent. Se faire arrêter est honteux, on est catalogué “burn-out” et puis c’est qu’il est déjà trop tard.

J’ai pris des journées sans solde car je n’ai plus de CP. L’erreur fondamentale est de croire que ça va aller, qu’on peut tirer sur la corde indéfiniment. On a tous des limites mentales et physiques. Je parle souvent de respect, confiance, responsabilité. J’assume mes limites, mes faiblesses, mes failles.

J’ai besoin et envie de petites choses de rien qui sont l’essentiel. Je veux avoir suffisamment d’énergie pour passer du temps avec mon gosse, vivre ce moment comme un plaisir pas une charge supplémentaire. C’est terrible de dire ça, c’est pourtant bien le malaise de cette société où on doit tellement courir que les bonheurs/plaisirs qui nous restent ressemblent à des contraintes.

La pause s’impose. Il est urgent de s’occuper de soi, se faire plaisir. Personne ne le fera pour vous, à votre place. La société au contraire vous poussera toujours à courir davantage. Il faut trouver cet équilibre subtil entre ce qu’on est, ce qu’on a, ce qu’on veut devenir et avoir. Ainsi que le bon rythme.

La fin du début

samedi 4 août 2018 à 08:15

Une page se tourne.

Il y a 3 ans vous m’auriez demandé mon niveau sur Lignux, l’écriture, le blogging, j’aurais dit débutant. Aujourd’hui je m’occupe des Liens intéressants du Journal du hacker, je contribue au Jdh en veillant à maintenir une bonne ambiance dessus, je publie ici-même articles technique et de réflexion, je deviens sysadmin Linux, j’essaie de tendre la main à ceux qui veulent apprendre.

J’ai pris conscience après la publication de Autour de SSH que j’avais franchi un cap. Je me suis dit, “c’est bien”. J’ai émis une once de considération sur ce que j’ai fait depuis plus de 3 ans. Incroyable. Parfois je me dis que je suis un faux modeste, facile avec un syndrome de l’imposteur. J’ai publié Autour de SSH, je m’attendais à ce qu’on me corrige, qu’on me dise que j’étais passé à côté d’un truc énorme mais rien. Du coup je regarde mon article avec un autre œil comme si c’était le jalon d’une construction collective. J’ai partagé mes connaissances/découvertes/expériences et participé – enfin je l’espère – à une meilleure utilisation de SSH.

Je me rends compte à quel point je partage et combien c’est difficile : le temps et l’énergie que j’y consacre, le nombre dérisoire de contributions, les critiques, la peur du ridicule et de ne pas être à la hauteur. J’ai changé. J’ai perdu cette candeur, cette légèreté d’avant. Je monte sur le ring avec les gants, pas pour donner des coups mais prêt à en recevoir, à me défendre en conséquence.

J’échange avec des pointures qui s’ignorent : Lord, tranche, Iceman, Buzut… des gens simples qui font des choses énormes. Je fais à présent partie d’une chose plus grande que moi, le Libre. J’espère y apporter des contributions utiles et positives mais c’est plus comme avant… moins chaleureux, moins drôle, trop sérieux.

Plus j’avance dans le Libre, plus je m’éloigne de “faire ce qui me ressemble”. Je ne me prends guère au sérieux, je préfère déconner qu’autre chose, contrairement à d’autres j’ai bien conscience qu’on parle seulement informatique et qu’on n’est pas en train de chercher un remède contre le cancer. La faim dans le monde, l’éducation, l’accès à l’eau, l’égalité… tellement de choses plus importantes.

Une autre s’ouvre.

En retour : Raspberry Pi remplacée

mardi 31 juillet 2018 à 22:00

Comme je l’expliquais dans mon article précédent, mon Pi était en panne. La véritable cause de la panne est le boîtier Aukru acheté et utilisé (que je déconseille fortement du coup). Il est mal découpé, ça a appuyé sur la carte SD conduisant à désolidariser le slot Micro SD Card de la carte Pi.

Je précise que je suis sûr du diagnostic, en appuyant sur la carte SD j’ai pu démarrer le système d’exploitation, les connecteurs faisant alors contact. J’ai essayé de trouver une solution pour maintenir appuyée la carte SD sur la carte Pi sans succès, j’ai accentué le problème. Ça m’a gonflé, j’ai jeté la carte Pi et ce pu%!*$ de boîtier.

Du coup je suis passé à une Raspberry Pi 3 Modèle B+ (installé et fonctionnel à l’heure qu’il est) avec le boîtier officiel en noir. La découpe est nickel, le Pi rentre parfaitement dedans, la différence est flagrante entre l’ancien boîtier Aukru et celui-ci.

La conclusion de cette mésaventure est que dans la jungle des accessoires autour de la Raspberry Pi, il vaut mieux parfois privilégier les accessoires officiels. J’avais pris le kit Aukru pour le prix, le ventilo (finalement trop bruyant) et le boîtier transparent, mauvais choix.

Tcho !