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. -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/11725781.apn5udr...@tonton.team1664.org