🤯 Quand les problèmes matériels deviennent mentaux (putain de Raspino)

Par OctoSpacc

- 13 minutes de lecture - 2657 mots

Prudence

Le contenu de cette page a été entièrement et automatiquement traduit en français, à partir de Italiano. Il peut donc contenir toutes sortes d’erreurs.

Jusqu'à il y a 2 mois, mon royaume de Rasperino était à sa splendeur maximale : l'instance Misskey, mise en place à peine 2 semaines plus tôt, < strong>elle allait génial, et maintenant (presque) tout semblait destiné à bien continuer...
Et au lieu de cela, des problèmes sont survenus. Disons qu'il m'a fallu un peu de temps pour m'en rendre compte, car ils se sont développés d'une manière étrangement graduelle.

Les premières fissures

J'ai remarqué la première chose vraiment étrange vers le début du mois de décembre, lorsque j'ai réalisé que le système pouvait planter en essayant d'effectuer une opération très banale mais < strong> spécification : créer une grande archive de fichiers (compressés ou non)... avec n'importe quel programme.
Ce petit inconvénient a, à son tour, provoqué un problème secondaire... J'y arrive.
Cependant, je n'y ai pas prêté trop attention. Comment pourrais-je ? Le reste, s'il n'était pas touché, fonctionnait, mis une légère dégradation des performances due au propre travail de Misskey.

Le premier effondrement

Mais ensuite, ces 2 autres semaines de paix relative se sont écoulées et je me réveille < /a> avec le serveur crashé, et qui meurt gravement après l'un de mes redémarrages manuels (débrancher et rebrancher l'alimentation, c'est le seul moyen). Après 2 jours de recherches très compliquées je l'ai fait Je n'ai pas vraiment compris quelle était la cause générale du problème, mais seulement le symptôme le plus grave, et j'étais maintenant presque convaincu que, d'une manière mystique > Misskey a réussi à lui seul à démonter l'intégralité du serveur, qui a recommencé à fonctionner correctement sans que ce logiciel particulier ne soit exécuté. Bon, il y avait une certaine logique dans mon raisonnement, étant donné que de toute façon l'utilisation moyenne du CPU et de la RAM était élevée (même si elle ne saturait pas complètement <). br> Cependant, les jours suivants, avec quelques tests, j'ai découvert que le serveur ne plantait pas à cause du serveur de microblogging, mais à cause de ce qu'il fait office de base de données : PostgreSQL (dans Docker). Si j'exécutais Misskey sur mon PC, mais que je le laissais se connecter à la base de données du Raspino, en quelques secondes, avec l'arrivée de tant de notes, le serveur fruité mourait.

De toute façon, à présent, la nécessité d'installer autre chose était évidente pour moi, car j'étais convaincu que Misskey était trop lourd, et tant pis.
Pendant 2 jours J'ai essayé Epicyon, une plateforme pour le moins particulière... et l'expérience n'a pas été vraiment agréable, mais je Cette réflexion était complète, étant donné que j'ai écrit quatre mille mots dans mon article dédié. Immédiatement après, j'ai décidé d'essayer un autre logiciel que je n'avais jamais vu auparavant, à savoir GoToSocial< /a>. Avec ce dernier, bien qu'il soit déclaré de qualité alpha (et en fait il a quelques problèmes), je me suis retrouvé - parce que hélas maintenant c'est fini... J'y arrive, j'y arrive - très bien, mais < strong>ce n'est pas le sujet .

Problèmes de plus en plus suspects

Quelques jours plus tard, ces étranges plantages ont recommencé à apparaître, mais cette fois ils étaient décidément suspects, car l'utilisation générale des ressources du système était faible. J'ai essayé de lire les logs système de manière productive, mais ma patience avait maintenant atteint la limite, et avec elle ma lucidité, donc chaque jour, j'ai cherché la moindre erreur suspecte mais lisible, en me concentrant là-dessus et en ignorant complètement l'erreur illisible qui était toujours devant moi.

À présent, juste par désespoir, mais pas parce que j'ai compris par raisonnement que c'était là le problème, je décide de changer la microSD carte, et maintenant que je l'ai fait, je regrette amèrement... de ne pas avoir essayé avant ! C'était là le problème, imprudent Maremme !
La bonne chose est que la veille j'avais fait une vérification des systèmes de fichiers (ext4), à la fois de la carte et de mon disque dur USB, et tout était ressorti (à peu près) propre, j'avais donc exclu a priori les problèmes matériels : "si les fichiers ne sont pas corrompus..." ai-je pensé.
À peu près au même moment (le destin a décidé que les secours devaient arriver en retard !), cependant, une personne m'a donné un coup de main pour comprendre ce que disaient ces lignes indéchiffrables, qui ressemblaient à quelque chose..

27 décembre 06:32:35 noyau : [27230.964650] INFO : tâche kworker/2:0:21874 bloquée pendant plus de 860 secondes.
27 décembre 06:32:35 noyau : [27230.964693] Entaché : G C 5.15.76-v7+ #1597
27 décembre 06:32:35 noyau : [27230.964709] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" désactive ce message.
27 décembre 06:32:35 noyau : [27230.964723] tâche : kworker/2:0 état : pile D : 0 pid : 21874 ppid : 2 indicateurs : 0x00000000
27 décembre 06:32:35 noyau : [27230.964760] File d'attente : events_freezable mmc_rescan
27 décembre 06:32:35 noyau : [27230.964801] Backtrace :
27 décembre 06:32:35 noyau : [27230.964824] [<80a4ff38>] (__schedule) de [<80a50a7c>] (schedule+0x7c/0x134)
27 décembre 06:32:35 noyau : [27230.964868] r10:81f90800 r9:ffffe000 r8:00000000 r7:00000000 r6:60000013 r5:8d368000
27 décembre 06:32:35 noyau : [27230.964884] r4:ffffe000
27 décembre 06:32:35 noyau : [27230.964896] [<80a50a00>] (programme) de [<8083f658>] (__mmc_claim_host+0xe0/0x238)
27 décembre 06:32:35 noyau : [27230.964929] r5:81f90a18 r4:00000002
27 décembre 06:32:35 noyau : [27230.964942] [<8083f578>] (__mmc_claim_host) de [<8083f7e8>] (mmc_get_card+0x38/0x3c)
27 décembre 06:32:35 noyau : [27230.964979] r10:baaf8205 r9:00000000 r8:baaf8200 r7:00000080 r6:baaf4b80 r5:00000000
27 décembre 06:32:35 noyau : [27230.964994] r4:81f91800
27 décembre 06:32:35 noyau : [27230.965007] [<8083f7b0>] (mmc_get_card) de [<80849238>] (mmc_sd_detect+0x24/0x7c)
27 décembre 06:32:35 noyau : [27230.965039] r5:81f90800 r4:81f90800
27 décembre 06:32:35 noyau : [27230.965052] [<80849214>] (mmc_sd_detect) de [<80841ca4>] (mmc_rescan+0xac/0x2d4)
27 décembre 06:32:35 noyau : [27230.965083] r5:81f90800 r4:81f90a7c
27 décembre 06:32:35 noyau : [27230.965096] [<80841bf8>] (mmc_rescan) de [<8013e158>] (process_one_work+0x250/0x57c)
27 décembre 06:32:35 noyau : [27230.965140] r9:00000000 r8:baaf8200 r7:00000080 r6:baaf4b80 r5:8e898f00 r4:81f90a7c
27 décembre 06:32:35 noyau : [27230.965153] [<8013df08>] (process_one_work) de [<8013e4e4>] (worker_thread+0x60/0x5c4)
27 décembre 06:32:35 noyau : [27230.965195] r10:baaf4b80 r9:81003d00 r8:baaf4b98 r7:00000008 r6:baaf4b80 r5:8e898f18
27 décembre 06:32:35 noyau : [27230.965210] r4:8e898f00
27 décembre 06:32:35 noyau : [27230.965223] [<8013e484>] (worker_thread) de [<80146804>] (kthread+0x178/0x194)
27 décembre 06:32:35 noyau : [27230.965264] r10:837c4000 r9:8d3a7e74 r8:00000000 r7:8e898f00 r6:8013e484 r5:8285ee00
27 décembre 06:32:35 noyau : [27230.965279] r4:8d0d3640
27 décembre 06:32:35 noyau : [27230.965291] [<8014668c>] (kthread) de [<801000d4>] (ret_from_fork+0x14/0x20)
27 décembre 06:32:35 noyau : [27230.965321] Pile d'exceptions (0x837c5fb0 à 0x837c5ff8)
27 décembre 06:32:35 noyau : [27230.965341] 5fa0 : 00000000 00000000 00000000 00000000
27 décembre 06:32:35 noyau : [27230.965363] 5fc0 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
27 décembre 06:32:35 noyau : [27230.965383] 5fe0 : 00000000 00000000 00000000 00000000 00000013 00000000
27 décembre 06:32:35 noyau : [27230.965405] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:8014668c
27 décembre 06:32:35 noyau : [27230.965420] r4:8285ee00

Chaque fois qu'une erreur comme celle-ci se produisait, tout le système mourait très gravement : maladie pour les petits robots, mort< /strong> strong> au serveur HTTP (nginx), blessures à mes agrégateurs d'articles et de flux (wallabag et FreshRSS), au revoir pour toujours à tout ce qui me permet d'ouvrir un console via Internet sur Rasperino (SSH, Telnet, et même un serveur mis en place avec netcat). La seule chose qui a continué à fonctionner est la crachat constant de ce type exact d'erreur dans le fichier journal.
Maintenant, je sais que je suis fort, mais avec tous ces chiffres étranges dans mon chemin je ne pouvais absolument pas voir des mots comme mmc_get_card code> ou mmc_sd_detect ! Et donc je n'ai vraiment pas compris que peut-être, juste peut-être, la microSD cagona que j'avais choisie pour Raspi début septembre ( parmi ceux libres à la maison), quand je remettais ce pauvre petit ordinateur en serveur, il tendait à mourir.

La carte microSD qui a lentement réussi à me rendre fou. Notez l'absence de marques.

Je ne veux pas avoir recours à des lieux communs, mais cette fois il n'y a pas grand-chose à faire ! Je veux dire, la photo parle d'elle-même :

La présence d'une marque renommée n'est pas une garantie de qualité, mais l'absence de marque est certainement une promesse d'une qualité absente.

Bien que sur le PC, l'ancienne carte indésirable semble toujours fonctionner - j'ai pu le confirmer car au moins j'ai pu faire un dump de données - Je ne le fais pas Je ne veux plus avoir à gérer des trucs comme ça ! Je considère donc que c'est mal dans mon esprit.
Encore plus de temps a été perdu à flasher le dump sur une nouvelle carte, étant donné que les deux seules autres cartes dont je disposais à l'époque étaient respectivement de 4 et 32 Go, et je voulais vraiment mettre (après avoir supprimé divers journaux et caches, car la mémoire précédente était de 8 Go) tout sur celle de 4 Go, mais rien ne pouvait être fait ; et au final c'était 32 Go.

La paix violée

L'important est que, J'ai mis la nouvelle SD dans le serveur Raspberry, ces erreurs terrifiantes ne se sont plus produites et les gros problèmes ils ont disparu... ou du moins c'est ce que je pensais, je voulais, j'espérais.
Si cet article, qui aurait dû être publié à la fin de l’année dernière, n’est publié que maintenant, il y a des raisons. Immédiatement après avoir changé la carte SD, j'ai préféré attendre quelques jours, pour voir si les choses s'étaient vraiment calmées, et pour éviter de crier victoire trop tôt. J'ai bien fait !

Le disque souffrant

Hélas, en fait, ces autres choses vues dans les journaux ces derniers jours n'étaient pas d'énormes trous d'eau (encore troublés), notamment les erreurs que j'ai immédiatement reconnues liées au disque USB.
C'est quelque chose qui m'est déjà arrivé dans le passé avec un autre adaptateur USB pour disques SATA 2,5", même sur différentes machines (à l'époque où j'utilisais ma console Nintendo Switch comme serveur...), mais avec celui-ci qui J'utilise maintenant il n'y a jamais eu de problèmes Et pourtant maintenant, d'après ce que je peux voir, il se déconnecte de l'hôte de manière aléatoire, < strong>mourirtous ces processus qui dépendent des fichiers qui se trouvent sur ce disque, comme s'il y avait soudainement des moments où toute combinaison d'adaptateurs SATA et de câbles USB ne reçoit pas assez de puissance (à la fois court et long), le disque fonctionne toujours très bien sur PC, donc le problème vient clairement du Raspino >... mais allez comprendre pourquoi !

Ils me disent que les ports USB-A du Raspi sont nuls par nature[citation requise (?)], mais le point c'est ce qui fonctionnait jusqu'à récemment (tous les 4) ! Une diode est cassée dans mon alimentation ? Que sur la carte de ce foutu ordinateur monocarte, un condensateur a explosé ? Que l'électricité dans ma maison n'est plus du 230V, mais du 229V, et donc le transformateur au lieu de donner 5 volts en sortie donne 4,98 ? ...Mais qu'est-ce que j'en sais.
Pour en revenir au monde réel, la seule hypothèse sensée me semble être la suivante : en insérant et en débranchant le connecteur d'alimentation dans son port (micro USB-B 2.0, cette grosse merde !!!), le les broches d'un côté ou les plots de l'autre seront usés, donc leur surface de contact est plus petite, donc la résistance électrique est plus grande, et donc l'appareil est alimenté avec une tension légèrement inférieure, et lorsqu'un périphérique a besoin d'absorber beaucoup , voici les patatracs.

Pour essayer de résoudre

Ne pas avoir d'autre Raspone comme celui-ci, et ne pas avoir d'autres alimentations 5V 3A, Je ne découvrirai jamais la vérité, mais la solution d'une manière ou d'une autre je dois le trouver par la force.
Après avoir attendu si longtemps que les problèmes du serveur n'ont fait que s'aggraver et que les temps d'arrêt sont beaucoup plus fréquents, je décide pour acheter un câble USB-A-Y. Dans le pire des cas, même si vous n'avez pas résolu le problème, il est toujours pratique d'avoir un câble de ce type car - malgré le respect des normes USB 1- certains appareils causent beaucoup de problèmes sans cela, et certains fabricants de périphériques merdiques recommandent même d'utiliser des câbles de ce type en cas de problème (et cependant, ils procèdent à ne pas en inclure un dans le colis, indécent !).

Une fois le câble arrivé, j'arrange toutes les connectiques et je remarque quelque chose de particulier : le courant qui vient de la deuxième alimentation USB pour alimenter le disque, peut strong> remonter le câble jusqu'à ce qu'il rentre dans le Pi. Le problème n'est pas tant le câble, qui fonctionne et respecte toutes les lois de la physique (même si ce n'est pas celles de la norme USB), mais plus le fait que le Raspberry n'a même pas, je ne sais pas, de diodes dans les ports USB-A. Et c'est un problème que je ne découvre pas, lisez simplement sur le forum officiel . Dans tous les cas, pour avoir un circuit configuré comme ceci :

  • Il n'y a aucun risque pour l'instrumentation ou l'environnement si vous utilisez des alimentations électriques appropriées en amont, et la mienne devrait être2;
  • Des problèmes pratiques il y en a, mais aussi des solutions et des arrangements : je pourrais, comme ils le suggèrent sur le forum, appliquer du ruban isolant sur le plot +5V du connecteur USB qui va chez Raspantino ; mais pour l'instant il n'y a pas vraiment de besoin, la seule chose à laquelle je dois faire attention c'est que les choses sont alimentées dans cet ordre, les rares fois où je me retrouve à devoir faire un hard reset du système :
    1. Disque USB (connecté au port du câble Y) ;
    2. Raspi (depuis son port d'alimentation) ;
    3. Après avoir attendu au moins ~10 secondes, disque connecté au Raspberry (connecteur de données du câble Y connecté au Raspberry).

Je ne sais pas pourquoi, d'autant plus que cela n'est pas nécessaire pour les redémarrages progressifs, mais sans cette procédure, le démarrage peut échouer.

Enfin, reposez-vous

En fin de compte, cependant, l'enfer semble terminé et le serveur fonctionne maintenant.
Les flammes ont cependant fait quelques dégâts : les bases de données de plusieurs de mes services hébergés sont devenues corrompues, et de 2 en particulier (GoToSocial, dont j'ai déjà parlé, et Peka, un chatbot basé sur une chaîne de Markov) J'ai des sauvegardes trop anciennes (depuis des semaines) car, avec le serveur en train de mourir, mes scripts de sauvegarde n'ont jamais réussi à fonctionner... et donc ces programmes sont toujours hors ligne maintenant, car je n'ai pas encore eu la force de me résigner à restaurer les anciennes sauvegardes.
Mais j'achète le câble un peu plus tôt, et j'éteins le serveur en attendant, pas vraiment, hein ?

En espérant que des choses comme celle-ci ne se reproduiront plus dans un avenir proche, sinon je deviendrai complètement et irrémédiablement fou à cause de ces foutus problèmes matériels, je vous salue et j'aimerais que tu n'aies jamais à putain autant que moi. 😔

🏷️ Notes et Références

  1. Cela a été une surprise pour moi aussi, mais la norme USB interdit les câbles en Y : voir Mise à jour 72; traduit en anglais,

    L'utilisation d'un câble "Y" (un câble avec deux connecteurs A) est interdite sur tout périphérique USB. Si un périphérique USB nécessite plus d'énergie que celle autorisée par la spécification USB pour laquelle il a été conçu, il doit être auto-alimenté.
    Eh bien, comme les règles sont belles, mais vient ensuite la réalité et la réflexion. un peu différemment. L'ensemble du monde réel utilise des câbles Y sans trop de chichi. ↩

  2. (Les deux 5 V)

    • Pour le Pi, une alimentation 3A (juste au-dessus de < a href="https://github.com/raspberrypi/documentation/blob/develop/documentation/asciidoc/computers/raspberry-pi/power-supplies.adoc" rel="noopener nofollow" target="_blank">le suggéré par Raspberry Foundation) qui était inclus dans un kit (hors ordinateur) d'accessoires pour le Raspante, par Aukru. Eh bien, après des années, ça n'a pas explosé, puis les critiques étaient bonnes quand même, et cette marque vend toujours de nouvelles alimentations, donc ça va...
    • Pour une puissance supplémentaire , un bloc 1A qui était inclus dans le package de mon ancien téléphone Huawei bas de gamme (également commercialisé en Europe), de 2017.
    ↩