Débugguer un crash et/ou un freeze

Support Debian
#1

Bonsoir tout le monde,

Je me tourne vers vous (et d’autres communeauté également) afin de savoir pourquoi mon Debian ne répond plus à rien par moment.

Informations :

  • RPI 3B
  • Yunohost (Raspbian donc)

Mon RPI est un serveur web en production, tournant sous Yunohost. J’ai à peu près tous les services web d’activé (web, ssl, mail, etc). Mon soucis est que par moment (entre 3 par jour à 1 fois par semaine), le PI ne répond plus. Les sites sont inaccessibles, le SSH ne se connecte plus, et localement parlant je n’y ai plus accès non plus. En gros il est allumé, et c’est tout. Je dois le rebooter électriquement, et il repart comme si de rien.

Donc je voulais savoir si - tout en le laissant allumé - je peux identifier le problème. J’ai déjà testé HTOP, et j’ai eu une capture d’écran qui ne montre pas grand chose.

Voici deux sujets sur lesquelles j’en discute, si jamais j’ai oublié des info’ !

https://www.raspberrypi.org/forums/viewtopic.php?f=65&t=195797&p=1225200

et

Je vous remercie :smiley:

#2

Salut
Si on imagine que c’est un problème de consommation de ressources ça peut se configurer en jouant sur les paramètres du noyau dans le fichier /etc/sysctl.conf
Les explications ici https://www.kernel.org/doc/Documentation/sysctl/vm.txt

En exemple, pas à copier bestialement, mon réglage perso sur un HP Pavilion dv7

vm.swappiness=75
vm.vfs_cache_pressure=50
vm.overcommit_memory=2
vm.overcommit_ratio=10

Si tu veux libérer la RAM vers le swap tu augmente la valeur de swappiness
si tu penses que ta RAM est assez volumineuse et que tu veux swapper le moins possible , tu diminues la valeur de swappiness
C’est plus ou moins empirique fonction du matériel et des applications utilisées :grinning:

Donc c’est à toi de faire des expérimentations pour voir si ça change quelque chose

#3

C’est Debian ou Raspbian ? Stretch ou autre ?

EDIT

Oups, désolé

#4

Mais comment savoir qu’il s’agit d’un problème de ressource ?

Enfin je veux dire, comment en déduire ça? A cause du RPI? Ou c’est juste une piste à suivre? :slight_smile:

#5

puisque tu dis que ça se fige, on peut envisager qu’il y a un problème de ressources, simplement par hypothèse

#6

Une autre hypothèse : un module du noyau le marque “Tainted” suite à quoi le risque de gel n’est pas nul et au bout d’un temps indéterminé, le système fige.

#7

Bonjour,

Une autre hypothèse la carte SD endommagée. J’ai vu ça une fois lors d’un dd pour sauvegarder le système.

A+

#8

Boonjour

Autre hypothèse : alimentation (du RPI ou/et des périphériques) un peu trop faible

#9

Bonjour,

Je viens de jetter un oeil sur le guide de dépannage Yunohost https://yunohost.org/#/troubleshooting_guide_fr

On y voit plusieurs pistes dont la RAM. Il faudrait pour valider si c’est pas une fuite de RAM passer la commande free -m périodiquement (en crontab) et envoyer le résultat dans un fichier de /tmp par exemple. Puis après le prochain plantage, consulter l’évolution de la consommation de RAM.

A+

#10

Ca fait plaisir de voir pas mal de personnes s’entraider ! :slight_smile:

Je vais tester un peu tout ça. Et je vous tiens au jus.

Edit: Voici les news:

  • Alimentation
    J’avais testé avec celle-ci: OUTPUT 5VDC 1.5A/9VDC 1.5A/ 12VDC 1.1A
    Puis j’ai switché sur une 2.3A
    Dans les deux cas, j’avais le problème.

  • /etc/sysctl.conf
    Après avoir lu la doc en français, je viens de tester de mettre un swappiness à 70. A suivre.

  • Tainted?
    J’ai pas bien compris ce passage. :confused:

  • Carte SD endommagée
    Je viens de la passer au crible avec le software SDCardFormatter qui vérifie les secteurs. A priori tout est OK.
    Et il s’agit d’un Sandisk 32GB (niveau espace, c’est good)

  • free -m
    Je viens de faire une crontab toutes les 30 minutes. A suivre !

En gros, on va voir un peu si les soucis sont toujours là !

Encore merci.

#11