[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Autopsie d'un "pseudo crash"



Le vendredi 8 juillet 2011 à 20:38:21, Yann COHEN a écrit :
> Bonjour,

’soir,

> Une machine distante fonctionnant sous Debian - Linux version
> 2.6.26-2-486 (Debian 2.6.26-15) - fait des siennes...
>[…]
> - sur la console plus de login cad pas de possibilité de
> saisir un login et l'appui sur enter ne fait rien,

  Un moyen pratique de vérifier un plantage hard : les DEL du 
clavier (ok, il faut des DEL sur le clavier…). D’abord, dans 
certains cas, le noyau a le temps de les mettre en clignotement 
pour signaler son désarroi. Sinon, si un LOCK (CAPS ou NUM) ne 
change pas leur état, c’est que le clavier ne répond pas, donc 
une forte probabilité¹ que le système est gelé.

¹: il y a aussi le cas où ce serait seulement le pilote clavier 
(ou le clavier débranché, haha) mais l’accès par le réseau 
permet d’éliminer cette possibilité.

  Et niveau bruit de la machine, pour vérifier si elle fait 
autre chose que réchauffer l’atmosphère ?

>[…]
> D'après ces symptômes je penche pour un manque de ressource
> comme de la mémoire (une fuite dans mes programmes zut
> alors) ou bien une ressource bloquante comme plus de process
> possible (welcome to zombieland), a priori je ne pense pas à
> un pb de disque à cause du comportement au reboot (à moins
> d'une saturation de /tmp).

  Plutôt problème matériel que logiciel (un arrêt CPU pour 
surchauffe p.ex.).
  Un problème logiciel laisse en général des traces (notamment 
ceux que tu envisages). P.ex. s’il n’a plus de mémoire, le noyau 
en récupère en tuant des applications et il le dit en console 
(sauf si les messages ont été bloqués) ou dans le dmesg (donc 
aussi sur disque).
  ’fin, pour la mémoire toujours, même s’il n’y a pas de message 
en direct, le noyau récupère et ne gèle pas la machine pour si 
peu.

  Il y aussi la possibilité d’un plantage pour cause de pilote 
matériel qui ne laisse pas trop le temps de laisser des traces.

> J'ai récupéré l'ensemble des log de /var/log, mais là je suis
> un peu comme une poule devant un couteau : que faut-il
> observer et ces fichiers sont-ils suffisant pour un
> diagnostique a posteriori ?

  Pas toujours suffisants. Si tu penses à la mémoire ou aux 
processus, regarde /var/log/dmesg ou kern.log.

> En observant les auth.log je constate qu'à partir d'un moment
> les log horaire du cron s'arrêtent et ce jusqu'au reboot
> suivant => ce qui me conforte dans mon hypothèse d'une
> saturation de ressources.

  Ce qui me conforte dans une hypothèse d’un gel matériel…

  Vérifie d’autres fichiers de log (p.ex. syslog qui, par 
défaut, met une marque toutes les 40min, et ne nécessite ni plus 
de mémoire ni de lancer d’autre processus pour cela).

> Par contre ni syslog, ni d'autres fichiers ne semblent
> indiquer la cause de ce "décès"...
> 
> Ceci me porte sur une autre piste : comment prévenir cette
> saturation avant qu'elle ne soit "létale" => c'est à dire
> forcer un reboot avant qu'il ne soit trop tard (ça ne
> corrige pas mais ça soulage) ?

  On ne règle pas un problème que l’on n’est pas sûr d’avoir…

  Si tu crois vraiment que c’est la bonne piste, tu peux déjà 
commencer par noter régulièrement le nombre de processus et 
l’utilisation mémoire dans un fichier de log. Il y a des 
programmes qui font cela (apt-cache search monitor)…

> Je pense au watchdog : la cible est une geode qui dispose
> d'un watchdog matériel/soft comment le mettre en service ?
> je n'ai pas trouvé de documentation "claire" sur ce sujet
> jusqu'à présent...
> 
> Je soumets tout cela à votre sagacité...

-- 
 Sylvain Sauvage


Reply to: