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

Re: Autopsie d'un "pseudo crash"



Bonsoir, 

Yann COHEN wrote:
> Bonjour,
> 
> Une machine distante fonctionnant sous Debian - Linux version
> 2.6.26-2-486 (Debian 2.6.26-15) - fait des siennes...
> 
> Et comme elle n'est pas juste à la porte d'à coté mais un peu plus loin
> je ne peux pas intervenir en direct lorsqu'elle est dans les choux.
> 
> Le "dernier observateur" sur cette machine a constaté les symptômes
> suivants :
> - plus de connexion réseau possible depuis l'extérieur cad pas de
>   réponse au ping et les connexions telnet sur des port connus restent
>   sans réponses ;
> - sur la console plus de login cad pas de possibilité de saisir un
>   login et l'appui sur enter ne fait rien, mais pas de message comme
>   quoi un problème système aurait survenu et aurait provoqué l'arrêt du
>   système ;
> - lorsque l'on branche et débranche un câble réseau, la machine réagit
>   et émet un bip (ifplugd est installé) ;

C'est ifplugd qui fait ça, ou c'est matériel ?

> - un reboot "au bouton" fait repartir la bête...
> 
> 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).
> 
> 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 ?
> 
> 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.
> 
> Par contre ni syslog, ni d'autres fichiers ne semblent indiquer la
> cause de ce "décès"...

Je pense à un problème de driver (hard lock), ou de mémoire (causant une 
boucle infinie dans un driver). Sinon on aurait des traces.
 
> 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) ?

Le démon watchdog est capable de faire ça (vérification charge, ping, 
mémoire, dernière modif d'un fichier, ...).
 
> 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...

A adapter, je ne sais pas quel est le driver pour le watchdog geode, mais ce 
n'est certainement pas le driver ipmi :

# aptitude install watchdog
(contrairement à la description du paquet, ce n'est pas qu'un watchdog soft, 
il est capable d'utiliser le matériel également)

# cat /etc/default/watchdog 
# Start watchdog at boot time? 0 or 1
run_watchdog=1
# Load module before starting watchdog
watchdog_module="ipmi_watchdog"
# Specify additional watchdog options here (see manpage).

# cat /etc/watchdog.conf
...
watchdog-device = /dev/watchdog
...

test :
# modprobe ipmi_watchdog (ou autre)
# watchdog -q -v
# tail -f /var/log/syslog

> Je soumets tout cela à votre sagacité...
> 
> Cordialement,
> 
> --
> Yann.



Reply to: