Raspberry pi 4 régulièrement inacessible

Bonjour,

J’ai un problème avec mon Raspberry : régulièrement (presque tous les jours) il devient inaccessible et il m’est impossible de m’y connecter en SSH ou d’accéder aux services hebergés (un super serveur Yunohost en plus…).

J’ai pu voir avec htop que le SWP était toujours à 100mo/100mo, en la passant à 2Go, elle reste aux alentours de 120/130mo à priori.

Coté matériel, il s’agit d’un Raspberry pi 4 avec 4Gb de RAM, dans un boitier Argon One M.2 et avec comme système de stockage un SSD M2 de 1 To, il n’y a d’ailleurs pas de carte SD et il boot donc sur USB.

Pour l’OS, j’ai installé Raspbian 64 bits.

Pour la température, je fais des relevés de temps en temps avec paste <(cat /sys/class/thermal/thermal_zone*/type) <(cat /sys/class/thermal/thermal_zone*/temp) | column -s $'\t' -t | sed 's/\(.\)..$/.\1°C/' et je dépasse rarement les 55°C.

La fréquence du processeur n’a pas été touchée, paste <(cat /sys/class/thermal/thermal_zone*/type) <(cat /sys/class/thermal/thermal_zone*/temp) | column -s $'\t' -t | sed 's/\(.\)..$/.\1°C/' me donne 1500000.

Pour le réseau, il est en Ethernet directement sur la box Orange (fibre).

Lors des moments où je ne peux plus accéder au Raspberry, je n’entends plus le ventilateur du boitier tourner mais par contre le boitier chauffe toujours ce qui me dit qu’il y a encore une activité. Lorsque je récupère la main (je restart parfois physiquement le Raspberry sinon je peux parfois attendre très longtemps comme une demie journée ou plus…), je consulte les logs système et je vois qu’il y en a quand meme pendant la durée de « la panne ».

Je ne suis pas vraiment un expert Linux et mes compétences d’analyse s’arretent ici… :’(.

J’espère que vous pourrez m’aider à diagnostiquer et résoudre mon problème car je l’aime bien ce petit RPI moi et il me rend de bons services sinon… :sleepy:.

Merci d’avance !

Sun.

hello,

si tu réinstalles un système de base sur une clé ou sur une SD, ( sans monter le SSD M2 de 1 To tu pourras constater:

  • si l’erreur subsiste on a sans doute affaire à un problème hardware
  • si tu ne constates pas d’erreur ça serait un problème lié a ton service yonohost ( un système ouvert sur l’internet peut être compromis )

autre possibilité l’alimentation je ne connais pas ce boîtier mais il semble qu’il nécessite une alim 3.5 A ( contre 3A pour celle du Rpi )

source:
https://yunohost.org/fr/security
https://www.kubii.fr/accessoires-cables-recalbox/3114-alimentation-argonone-pi-4-3272496303638.html

bonjour

J’ai exactement le meme soucis, mais sur un pi 3. Ceci est arrivé depuis que je suis passé en raspbian version Bulleye, je n’avais aucun probleme avec la version pécédente. Les logiciels tournant sont donc les memes (apache, php, mariadb, netstat), simplement upgradés lors de la mise à jour. Ce petit pi me sert pour un site web tout simple et pour une instance de Nextcloud (24) surtout pour stocker les photos.
Je ne vais pas tout redecrire, mais c’est effectivement tres troublant. plus de ssh, Apache ne repond plus non plus, l’outil netstat n’émet plus rien, mais le ping fonctionne encore.
J’ai egalement tout revalidé, swap mémoire température alimentation.
Bizarement, la « disparition » intervient plutot la nuit, j’en suis donc à soupçonner un cronjob qui planterait la mémoire.
Petit à petit je ressers l’étau, mais ca ne vient pas vite.
Donc @Suniron si tu trouves quelque chose, je suis preneur ! et vice versa bien sur, que fais tu tourner dessus ? :wink:

1 J'aime

Hey,

Bien content de n’être pas seul :blush:.

Bon, en fait, c’est désormais de l’histoire ancienne :partying_face:.

Dessus je fais tourner Docker avec deux ou trois applis que j’ai développé (un chat bot en Node.js et des trucs du genre), Yunohost donc avec un Wordpress, un client torrent, un serveur DLNA etc mais rien de fou.

Le moins clean dans l’histoire ça restait le fait que j’étais en boot USB sur un SSD M2 sur lequel j’avais d’abord installé raspbian 64 bits (sans interface graphique) puis déployé Yunohost dessus.

J’ai donc fais quelques tests de montée en charge avec d’autres OS sur carte SD et depuis un boot USB avec une clé USB et je n’ai pas reproduit le problème.

J’ai donc sauvegardé Yunohost en créant une archive depuis l’interface (ça marche super bien !) et fais un backup sur un Google Drive par sécurité (en utilisant RCLONE, c’est extra !), puis j’ai cette fois ci installé directement Yunohost 64 bits sur le Raspberry, résultat (no spoil) : plus de problème depuis une dizaine de jours !!!

Je ne peux que te recommander de réinstaller au propre ton système et restaurer ce dont tu as besoin (ça permet en plus de faire le tri :rofl:).

Je soupçonne une mise à jour qui aurait vrillé mais bon je n’ai pas de piste…

Bon courage et tiens nous au courant de ce qui fonctionne pour toi !

hello @Suniron, désolé je n’avais pas vu ta réponse.
Justement j’allais te repondre pour te dire que j’avais résolu mon probleme (également)
je n’ai pas tout réinstallé. Ce petit Pi n’est utilisé que pour des choses tres précises que j’ai en partie installé à la mano comme nextcloud, grav ou matomo.
J’ai simplement découvert des trucs étranges et les faits les plus notoires sont :

  • le swap n’était pas démarré (et mal configuré). En soit ça n’aurait pas du changer quoi que soit si ce n’est raler par manque de mémoire, mais ce n’était pas le cas.
  • J’ai supprimé 2 taches du cron spécifiques à nextcloud, mais… j’avais lu sur un autre forum qu’elles posait probleme à cause d’une config php. Sauf que meme en modifiant la config php, ça ne changeait rien. je les ai quand meme enlevées. (cela dit les lancer à la main ne plante pas)
  • J’ai optimisé MariaDB. Ca m’a pris du temps de tout comprendre. Cependant il y avait des trucs qui n’étaient pas adaptés. D’ailleurs, la résolution de nom intégré lors de requêtes ne me servait à rien puisque c’est mono serveur sans autre acces, et ça, ça l’a boosté !

J’utilise aussi https://app.netdata.cloud un super outil de surveillance (gratuit) on line qui m’a permis de voir que mon raid1 pédalait un peu dans la semoule, et que mon proc etait surchargé par moment. intéressant.

Bref, si je peux le dire comme ça, c’était des coups de tournevis un peu partout. Le cumul a visiblement fait son effet.
Nos deux posts serviront peut etre à d’autres :wink: