Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Linux Autres OS Linux Debian Autopsie d'un "pseudo crash"

Autopsie d'un "pseudo crash"

2 réponses
Avatar
Yann COHEN
Bonjour,

Une machine distante fonctionnant sous Debian - Linux version
2.6.26-2-486 (Debian 2.6.26-15) - fait des siennes...=20

Et comme elle n'est pas juste =C3=A0 la porte d'=C3=A0 cot=C3=A9 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=C3=A9 les sympt=C3=B4m=
es
suivants :
- plus de connexion r=C3=A9seau possible depuis l'ext=C3=A9rieur cad pas de
r=C3=A9ponse au ping et les connexions telnet sur des port connus restent
sans r=C3=A9ponses ;
- sur la console plus de login cad pas de possibilit=C3=A9 de saisir un
login et l'appui sur enter ne fait rien, mais pas de message comme
quoi un probl=C3=A8me syst=C3=A8me aurait survenu et aurait provoqu=C3=A9=
l'arr=C3=AAt du
syst=C3=A8me ;
- lorsque l'on branche et d=C3=A9branche un c=C3=A2ble r=C3=A9seau, la mach=
ine r=C3=A9agit
et =C3=A9met un bip (ifplugd est install=C3=A9) ;
- un reboot "au bouton" fait repartir la b=C3=AAte...

D'apr=C3=A8s ces sympt=C3=B4mes je penche pour un manque de ressource comme=
de la
m=C3=A9moire (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 =C3=A0 un pb de disque =C3=A0 cause du comportement =
au
reboot (=C3=A0 moins d'une saturation de /tmp).

J'ai r=C3=A9cup=C3=A9r=C3=A9 l'ensemble des log de /var/log, mais l=C3=A0 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'=C3=A0 partir d'un moment les log
horaire du cron s'arr=C3=AAtent et ce jusqu'au reboot suivant =3D> ce qui me
conforte dans mon hypoth=C3=A8se d'une saturation de ressources.

Par contre ni syslog, ni d'autres fichiers ne semblent indiquer la
cause de ce "d=C3=A9c=C3=A8s"...

Ceci me porte sur une autre piste : comment pr=C3=A9venir cette saturation
avant qu'elle ne soit "l=C3=A9tale" =3D> c'est =C3=A0 dire forcer un reboot=
avant
qu'il ne soit trop tard (=C3=A7a ne corrige pas mais =C3=A7a soulage) ?

Je pense au watchdog : la cible est une geode qui dispose d'un watchdog
mat=C3=A9riel/soft comment le mettre en service ? je n'ai pas trouv=C3=A9 de
documentation "claire" sur ce sujet jusqu'=C3=A0 pr=C3=A9sent...

Je soumets tout cela =C3=A0 votre sagacit=C3=A9...

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
Signaler un problème avec ce contenu

2 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Sylvain L. Sauvage
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, 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 ?

[…]
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 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.

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

--
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/
Avatar
Vincent Tondellier
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 r estent
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, l a 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 re ssource
bloquante comme plus de process possible (welcome to zombieland), a
priori je ne pense pas à un pb de disque à cause du comport ement 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 le s 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émo ire (causant une
boucle infinie dans un driver). Sinon on aurait des traces.

Ceci me porte sur une autre piste : comment prévenir cette satur ation
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 watchd og
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, 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

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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/