Autopsie d'un "pseudo crash"
Le
Yann COHEN
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 pe=
u 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ôm=
es
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 mach=
ine réagit
et émet un bip (ifplugd est installé) ;
- 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à j=
e 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"
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) ?
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é
Cordialement,
--
Yann.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20110708203821.7dd3761f@samyan.ianco.homelinux.org
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 pe=
u 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ôm=
es
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 mach=
ine réagit
et émet un bip (ifplugd est installé) ;
- 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à j=
e 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"
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) ?
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é
Cordialement,
--
Yann.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20110708203821.7dd3761f@samyan.ianco.homelinux.org
âsoir,
Un moyen pratique de vérifier un plantage hard : les DEL du
clavier (ok, il faut des DEL sur le clavierâ¦). Dâabord, dan s
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 ?
Plutôt problème matériel que logiciel (un arrêt CPU p our
surchauffe p.ex.).
Un problème logiciel laisse en général des traces (notamme nt
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 (don c
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.
Pas toujours suffisants. Si tu penses à la mémoire ou aux
processus, regarde /var/log/dmesg ou kern.log.
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).
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)â¦
--
Sylvain Sauvage
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Yann COHEN wrote:
C'est ifplugd qui fait ça, ou c'est matériel ?
Je pense à un problème de driver (hard lock), ou de mémo ire (causant une
boucle infinie dans un driver). Sinon on aurait des traces.
Le démon watchdog est capable de faire ça (vérification charge, ping,
mémoire, dernière modif d'un fichier, ...).
A adapter, je ne sais pas quel est le driver pour le watchdog geode, ma is ce
n'est certainement pas le driver ipmi :
# aptitude install watchdog
(contrairement à la description du paquet, ce n'est pas qu'un watc hdog 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
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/