J'utilise un pc sous mandrake 10 comme proxy et serveur de fichier. Il
n'a pas d'écran.
De temps en temps, (en moyenne tous les 15 jours) il plante, et ce même
quand il est au repos (le réseau n'est pas utilisé). C'est à dire que le
serveur de fichier ne répond plus, le proxy non plus, VNC non plus...
Si je branche un écran, ça reste noir.
Je suis donc obligé de rebooter.
un test smartctl ne détecte pas d'anomalie.
Quels logs faut-il fouiller pour essayer de déterminer la cause de ce
plantage ?
J'utilise un pc sous mandrake 10 comme proxy et serveur de fichier. Il n'a pas d'écran. De temps en temps, (en moyenne tous les 15 jours) il plante, et ce même quand il est au repos (le réseau n'est pas utilisé). C'est à dire que le serveur de fichier ne répond plus, le proxy non plus, VNC non plus... Si je branche un écran, ça reste noir.
Je suis donc obligé de rebooter.
un test smartctl ne détecte pas d'anomalie.
Quels logs faut-il fouiller pour essayer de déterminer la cause de ce plantage ?
Il faut d'abord regarder dans /var/logs/messages
-- Bruno
Bonjour,
J'utilise un pc sous mandrake 10 comme proxy et serveur de fichier. Il
n'a pas d'écran.
De temps en temps, (en moyenne tous les 15 jours) il plante, et ce même
quand il est au repos (le réseau n'est pas utilisé). C'est à dire que le
serveur de fichier ne répond plus, le proxy non plus, VNC non plus...
Si je branche un écran, ça reste noir.
Je suis donc obligé de rebooter.
un test smartctl ne détecte pas d'anomalie.
Quels logs faut-il fouiller pour essayer de déterminer la cause de ce
plantage ?
J'utilise un pc sous mandrake 10 comme proxy et serveur de fichier. Il n'a pas d'écran. De temps en temps, (en moyenne tous les 15 jours) il plante, et ce même quand il est au repos (le réseau n'est pas utilisé). C'est à dire que le serveur de fichier ne répond plus, le proxy non plus, VNC non plus... Si je branche un écran, ça reste noir.
Je suis donc obligé de rebooter.
un test smartctl ne détecte pas d'anomalie.
Quels logs faut-il fouiller pour essayer de déterminer la cause de ce plantage ?
Il faut d'abord regarder dans /var/logs/messages
-- Bruno
ludovic Thebault
Bruno Patri wrote:
Il faut d'abord regarder dans /var/logs/messages
Pas de messages marquant.
La dernière inscription est celle d'un cron hourly tout ce qu'il y a de classique.
Bruno Patri wrote:
Il faut d'abord regarder dans /var/logs/messages
Pas de messages marquant.
La dernière inscription est celle d'un cron hourly tout ce qu'il y a de
classique.
La dernière inscription est celle d'un cron hourly tout ce qu'il y a de classique.
Un test de la RAM avec Memtest ? Mais bon, en cas de RAm defectueuse les plantages sont plus fréquents... Un test du disque dur ? fsck, badblock ?
-- Bruno
ludovic Thebault
Bruno Patri wrote:
Bruno Patri wrote:
Il faut d'abord regarder dans /var/logs/messages
Pas de messages marquant.
La dernière inscription est celle d'un cron hourly tout ce qu'il y a de classique.
Un test de la RAM avec Memtest ? Mais bon, en cas de RAm defectueuse les plantages sont plus fréquents... Un test du disque dur ? fsck, badblock ?
J'ai installé et essayé smartctl, tout à l'air correct (enfin d'après ce
que je comprend). Par contre après chaque reboot sauvage, le fsck détecte des erreurs et je dois relancer un scan approfondi en appuyant sur "y" au clavier (pour cela j'ai du laisser un clavier branché à l'UC. Après tout roule.
PS : peut-on tester le DD autrement qu'au boot ? Je parle de tester, pas de corriger d'éventuelles erreurs.
Merci.
Bruno Patri wrote:
Bruno Patri wrote:
Il faut d'abord regarder dans /var/logs/messages
Pas de messages marquant.
La dernière inscription est celle d'un cron hourly tout ce qu'il y a
de classique.
Un test de la RAM avec Memtest ? Mais bon, en cas de RAm defectueuse les
plantages sont plus fréquents...
Un test du disque dur ? fsck, badblock ?
J'ai installé et essayé smartctl, tout à l'air correct (enfin d'après ce
que je comprend).
Par contre après chaque reboot sauvage, le fsck détecte des erreurs et
je dois relancer un scan approfondi en appuyant sur "y" au clavier (pour
cela j'ai du laisser un clavier branché à l'UC.
Après tout roule.
PS : peut-on tester le DD autrement qu'au boot ? Je parle de tester, pas
de corriger d'éventuelles erreurs.
La dernière inscription est celle d'un cron hourly tout ce qu'il y a de classique.
Un test de la RAM avec Memtest ? Mais bon, en cas de RAm defectueuse les plantages sont plus fréquents... Un test du disque dur ? fsck, badblock ?
J'ai installé et essayé smartctl, tout à l'air correct (enfin d'après ce
que je comprend). Par contre après chaque reboot sauvage, le fsck détecte des erreurs et je dois relancer un scan approfondi en appuyant sur "y" au clavier (pour cela j'ai du laisser un clavier branché à l'UC. Après tout roule.
PS : peut-on tester le DD autrement qu'au boot ? Je parle de tester, pas de corriger d'éventuelles erreurs.
Merci.
TiChou
Dans le message <news:41a5a04d$0$1165$, *ludovic Thebault* tapota sur f.c.o.l.configuration :
Bonjour,
Bonjour,
J'utilise un pc sous mandrake 10 comme proxy et serveur de fichier. Il n'a pas d'écran. De temps en temps, (en moyenne tous les 15 jours) il plante, et ce même quand il est au repos (le réseau n'est pas utilisé). C'est à dire que le serveur de fichier ne répond plus, le proxy non plus, VNC non plus... Si je branche un écran, ça reste noir.
Si l'écran reste noir, c'est que certainement le noyau a passé la console en mode « écran de veille ». Pour désactiver l'écran de veille de la console, il faudrait lancer la commande 'setterm -powersave' juste après le démarrage.
Il y a-t-il un clavier de branché sur cette machine ? Si oui, quels sont l'état des leds du clavier ? Si elles clignotent, c'est qu'il y a eu un kernel panic. Si la touche Verr Num du clavier n'agit plus, c'est-à-dire si elle ne fait plus changer l'état de la led Num Lock, c'est que le système semble figer. Sinon, c'est que le système répond toujours et qu'il n'est pas totalement planté.
Dans tous les cas tout n'est pas totalement perdu si votre noyau a été compilé avec l'option 'Magic SysRq key'. Vous pouvez en effet tenter reprendre la main sur votre système figé avec les combinaisons de touches Alt+SysRq+touche. Pour plus de détails sur ces combinaisons de touches :
Quels logs faut-il fouiller pour essayer de déterminer la cause de ce plantage ?
Tous les fichiers logs présents dans le répertoire /var/log et en particulier le fichier de log des messages du noyau (kern.log, kernel, etc. selon les distributions). Vous pouvez aussi configurer votre gestionnaire de logs pour qu'il renvoit tous les messages vers une autre machine. Si votre gestionnaire est sysklogd, il suffit d'ajouter dans votre fichier syslog.conf la ligne suivante :
*.* @toto
et tous les messages seront alors renvoyés vers la machine toto.
Merci.
De rien.
-- TiChou
Dans le message <news:41a5a04d$0$1165$8fcfb975@news.wanadoo.fr>,
*ludovic Thebault* tapota sur f.c.o.l.configuration :
Bonjour,
Bonjour,
J'utilise un pc sous mandrake 10 comme proxy et serveur de fichier. Il n'a
pas d'écran.
De temps en temps, (en moyenne tous les 15 jours) il plante, et ce même
quand il est au repos (le réseau n'est pas utilisé). C'est à dire que le
serveur de fichier ne répond plus, le proxy non plus, VNC non plus...
Si je branche un écran, ça reste noir.
Si l'écran reste noir, c'est que certainement le noyau a passé la console en
mode « écran de veille ». Pour désactiver l'écran de veille de la console,
il faudrait lancer la commande 'setterm -powersave' juste après le
démarrage.
Il y a-t-il un clavier de branché sur cette machine ? Si oui, quels sont
l'état des leds du clavier ? Si elles clignotent, c'est qu'il y a eu un
kernel panic. Si la touche Verr Num du clavier n'agit plus, c'est-à-dire si
elle ne fait plus changer l'état de la led Num Lock, c'est que le système
semble figer. Sinon, c'est que le système répond toujours et qu'il n'est pas
totalement planté.
Dans tous les cas tout n'est pas totalement perdu si votre noyau a été
compilé avec l'option 'Magic SysRq key'. Vous pouvez en effet tenter
reprendre la main sur votre système figé avec les combinaisons de touches
Alt+SysRq+touche.
Pour plus de détails sur ces combinaisons de touches :
Quels logs faut-il fouiller pour essayer de déterminer la cause de ce
plantage ?
Tous les fichiers logs présents dans le répertoire /var/log et en
particulier le fichier de log des messages du noyau (kern.log, kernel, etc.
selon les distributions).
Vous pouvez aussi configurer votre gestionnaire de logs pour qu'il renvoit
tous les messages vers une autre machine. Si votre gestionnaire est
sysklogd, il suffit d'ajouter dans votre fichier syslog.conf la ligne
suivante :
*.* @toto
et tous les messages seront alors renvoyés vers la machine toto.
Dans le message <news:41a5a04d$0$1165$, *ludovic Thebault* tapota sur f.c.o.l.configuration :
Bonjour,
Bonjour,
J'utilise un pc sous mandrake 10 comme proxy et serveur de fichier. Il n'a pas d'écran. De temps en temps, (en moyenne tous les 15 jours) il plante, et ce même quand il est au repos (le réseau n'est pas utilisé). C'est à dire que le serveur de fichier ne répond plus, le proxy non plus, VNC non plus... Si je branche un écran, ça reste noir.
Si l'écran reste noir, c'est que certainement le noyau a passé la console en mode « écran de veille ». Pour désactiver l'écran de veille de la console, il faudrait lancer la commande 'setterm -powersave' juste après le démarrage.
Il y a-t-il un clavier de branché sur cette machine ? Si oui, quels sont l'état des leds du clavier ? Si elles clignotent, c'est qu'il y a eu un kernel panic. Si la touche Verr Num du clavier n'agit plus, c'est-à-dire si elle ne fait plus changer l'état de la led Num Lock, c'est que le système semble figer. Sinon, c'est que le système répond toujours et qu'il n'est pas totalement planté.
Dans tous les cas tout n'est pas totalement perdu si votre noyau a été compilé avec l'option 'Magic SysRq key'. Vous pouvez en effet tenter reprendre la main sur votre système figé avec les combinaisons de touches Alt+SysRq+touche. Pour plus de détails sur ces combinaisons de touches :
Quels logs faut-il fouiller pour essayer de déterminer la cause de ce plantage ?
Tous les fichiers logs présents dans le répertoire /var/log et en particulier le fichier de log des messages du noyau (kern.log, kernel, etc. selon les distributions). Vous pouvez aussi configurer votre gestionnaire de logs pour qu'il renvoit tous les messages vers une autre machine. Si votre gestionnaire est sysklogd, il suffit d'ajouter dans votre fichier syslog.conf la ligne suivante :
*.* @toto
et tous les messages seront alors renvoyés vers la machine toto.
Merci.
De rien.
-- TiChou
Bruno Patri
Bruno Patri wrote:
Bruno Patri wrote:
Il faut d'abord regarder dans /var/logs/messages
Pas de messages marquant.
La dernière inscription est celle d'un cron hourly tout ce qu'il y a de classique.
Un test de la RAM avec Memtest ? Mais bon, en cas de RAm defectueuse les plantages sont plus fréquents... Un test du disque dur ? fsck, badblock ?
J'ai installé et essayé smartctl, tout à l'air correct (enfin d'après ce
que je comprend). Par contre après chaque reboot sauvage, le fsck détecte des erreurs et je dois relancer un scan approfondi en appuyant sur "y" au clavier (pour cela j'ai du laisser un clavier branché à l'UC. Après tout roule.
PS : peut-on tester le DD autrement qu'au boot ? Je parle de tester, pas de corriger d'éventuelles erreurs.
Pas sur des partitions montées, il vaut mieux éviter. Pour des tests approfondis sur les disques dur sans démarrer dessus, il y a des boites à outils comme UltimateBootCD.
-- Bruno
Bruno Patri wrote:
Bruno Patri wrote:
Il faut d'abord regarder dans /var/logs/messages
Pas de messages marquant.
La dernière inscription est celle d'un cron hourly tout ce qu'il y a
de classique.
Un test de la RAM avec Memtest ? Mais bon, en cas de RAm defectueuse
les plantages sont plus fréquents...
Un test du disque dur ? fsck, badblock ?
J'ai installé et essayé smartctl, tout à l'air correct (enfin d'après ce
que je comprend).
Par contre après chaque reboot sauvage, le fsck détecte des erreurs et
je dois relancer un scan approfondi en appuyant sur "y" au clavier (pour
cela j'ai du laisser un clavier branché à l'UC.
Après tout roule.
PS : peut-on tester le DD autrement qu'au boot ? Je parle de tester, pas
de corriger d'éventuelles erreurs.
Pas sur des partitions montées, il vaut mieux éviter. Pour des tests
approfondis sur les disques dur sans démarrer dessus, il y a des boites
à outils comme UltimateBootCD.
La dernière inscription est celle d'un cron hourly tout ce qu'il y a de classique.
Un test de la RAM avec Memtest ? Mais bon, en cas de RAm defectueuse les plantages sont plus fréquents... Un test du disque dur ? fsck, badblock ?
J'ai installé et essayé smartctl, tout à l'air correct (enfin d'après ce
que je comprend). Par contre après chaque reboot sauvage, le fsck détecte des erreurs et je dois relancer un scan approfondi en appuyant sur "y" au clavier (pour cela j'ai du laisser un clavier branché à l'UC. Après tout roule.
PS : peut-on tester le DD autrement qu'au boot ? Je parle de tester, pas de corriger d'éventuelles erreurs.
Pas sur des partitions montées, il vaut mieux éviter. Pour des tests approfondis sur les disques dur sans démarrer dessus, il y a des boites à outils comme UltimateBootCD.
-- Bruno
ludovic Thebault
Bruno Patri wrote:
Pas sur des partitions montées, il vaut mieux éviter. Pour des tests approfondis sur les disques dur sans démarrer dessus, il y a des boites à outils comme UltimateBootCD.
Le bug est réapparu. Le clavier ne répond pas => donc gèle complet du système, reboot obligatoire. Après fsck, je vois que le nombre de blocks diminue... Signe que le DD est fatigué non ?
Bruno Patri wrote:
Pas sur des partitions montées, il vaut mieux éviter. Pour des tests
approfondis sur les disques dur sans démarrer dessus, il y a des boites
à outils comme UltimateBootCD.
Le bug est réapparu.
Le clavier ne répond pas => donc gèle complet du système, reboot
obligatoire.
Après fsck, je vois que le nombre de blocks diminue... Signe que le DD
est fatigué non ?
Pas sur des partitions montées, il vaut mieux éviter. Pour des tests approfondis sur les disques dur sans démarrer dessus, il y a des boites à outils comme UltimateBootCD.
Le bug est réapparu. Le clavier ne répond pas => donc gèle complet du système, reboot obligatoire. Après fsck, je vois que le nombre de blocks diminue... Signe que le DD est fatigué non ?
Nicolas George
Bruno Patri wrote in message <41a5d9ac$0$19788$:
Mais bon, en cas de RAm defectueuse les plantages sont plus fréquents...
Pas du tout, c'est extrêmement variable selon la quantité de bits défectueux et leur degré de défectuosité.
Bruno Patri wrote in message <41a5d9ac$0$19788$636a15ce@news.free.fr>:
Mais bon, en cas de RAm defectueuse les
plantages sont plus fréquents...
Pas du tout, c'est extrêmement variable selon la quantité de bits défectueux
et leur degré de défectuosité.
Mais bon, en cas de RAm defectueuse les plantages sont plus fréquents...
Pas du tout, c'est extrêmement variable selon la quantité de bits défectueux et leur degré de défectuosité.
Sebastien Kirche
[Je me suis un peu planté en rattachant ma réponse à un mauvais fil, je la remets ici]
Le 25 Nov 2004, ludovic Thebault a dit :
Le bug est réapparu. Le clavier ne répond pas => donc gèle complet du système, reboot obligatoire.
Es-tu sûr que la machine est complètement plantée ?
Le fait qu'il n'y ait plus d'affichage et que le clavier ne réponde plus (switch vers une autre console ou blocage majuscules inopérant) n'est pas une preuve.
Je m'explique : le week-end dernier j'ai gimp qui m'a fait crasher X suite à (semble-t-il) un souci d'allocation mémoire. Résultat : un tas de pixels à l'écran et clavier bloqué.
Cependant j'ai pu constater qu'il était toujours possible de se connecter sur la machine par ssh, ce qui m'a permis de déplanter le bousin *sans* rebooter.
Également, Bruno Mathieu m'a indiqué une solution pour débloquer le clavier si tu peux encore te logguer dessus à distance : kbd_mode (voir ci-dessous).
Tu peux aussi tenter un reboot propre dans ce cas.
Le 20 Nov 2004, Bruno Mathieu a formulé :
Sebastien Kirche a écrit:
- Plus de clavier : impossible de switcher sur une autre console pour dépatouiller, je remarque que même les diodes verrouillage majuscule et pavé numérique ne réagissent plus.
Bonjour,
Tu peux essayer kbd_mode à distance. Je me souviens de plantage de serveurs X sur sun : le clavier ne se remettait pas en mode ascii alors on ne pouvait plus rien faire sur une console. Rebooter n'était pas trop envisageable car plusieurs personnes faisaient tourner des process assez longs sur la machine. Kbd_mode à distance pour remettre le clavier en état a fonctionné.
Autrement il m'est arrivé que les diodes ne répondent plus mais que les touches magiques fonctionnent encore. Dans ce cas un alt-impr_écran-k me rend parfois la console (si noyau compilé avec support de Magic Keys).
Sébastien Kirche
[Je me suis un peu planté en rattachant ma réponse à un mauvais fil, je la
remets ici]
Le 25 Nov 2004, ludovic Thebault a dit :
Le bug est réapparu.
Le clavier ne répond pas => donc gèle complet du système, reboot
obligatoire.
Es-tu sûr que la machine est complètement plantée ?
Le fait qu'il n'y ait plus d'affichage et que le clavier ne réponde plus
(switch vers une autre console ou blocage majuscules inopérant) n'est pas
une preuve.
Je m'explique : le week-end dernier j'ai gimp qui m'a fait crasher X suite à
(semble-t-il) un souci d'allocation mémoire. Résultat : un tas de pixels à
l'écran et clavier bloqué.
Cependant j'ai pu constater qu'il était toujours possible de se connecter
sur la machine par ssh, ce qui m'a permis de déplanter le bousin *sans*
rebooter.
Également, Bruno Mathieu m'a indiqué une solution pour débloquer le clavier
si tu peux encore te logguer dessus à distance : kbd_mode (voir ci-dessous).
Tu peux aussi tenter un reboot propre dans ce cas.
Le 20 Nov 2004, Bruno Mathieu a formulé :
Sebastien Kirche a écrit:
- Plus de clavier : impossible de switcher sur une autre console
pour dépatouiller, je remarque que même les diodes verrouillage
majuscule et pavé numérique ne réagissent plus.
Bonjour,
Tu peux essayer kbd_mode à distance. Je me souviens de plantage de
serveurs X sur sun : le clavier ne se remettait pas en mode ascii alors on
ne pouvait plus rien faire sur une console. Rebooter n'était pas trop
envisageable car plusieurs personnes faisaient tourner des process assez
longs sur la machine. Kbd_mode à distance pour remettre le clavier en état
a fonctionné.
Autrement il m'est arrivé que les diodes ne répondent plus mais que les
touches magiques fonctionnent encore. Dans ce cas un alt-impr_écran-k me
rend parfois la console (si noyau compilé avec support de Magic Keys).
[Je me suis un peu planté en rattachant ma réponse à un mauvais fil, je la remets ici]
Le 25 Nov 2004, ludovic Thebault a dit :
Le bug est réapparu. Le clavier ne répond pas => donc gèle complet du système, reboot obligatoire.
Es-tu sûr que la machine est complètement plantée ?
Le fait qu'il n'y ait plus d'affichage et que le clavier ne réponde plus (switch vers une autre console ou blocage majuscules inopérant) n'est pas une preuve.
Je m'explique : le week-end dernier j'ai gimp qui m'a fait crasher X suite à (semble-t-il) un souci d'allocation mémoire. Résultat : un tas de pixels à l'écran et clavier bloqué.
Cependant j'ai pu constater qu'il était toujours possible de se connecter sur la machine par ssh, ce qui m'a permis de déplanter le bousin *sans* rebooter.
Également, Bruno Mathieu m'a indiqué une solution pour débloquer le clavier si tu peux encore te logguer dessus à distance : kbd_mode (voir ci-dessous).
Tu peux aussi tenter un reboot propre dans ce cas.
Le 20 Nov 2004, Bruno Mathieu a formulé :
Sebastien Kirche a écrit:
- Plus de clavier : impossible de switcher sur une autre console pour dépatouiller, je remarque que même les diodes verrouillage majuscule et pavé numérique ne réagissent plus.
Bonjour,
Tu peux essayer kbd_mode à distance. Je me souviens de plantage de serveurs X sur sun : le clavier ne se remettait pas en mode ascii alors on ne pouvait plus rien faire sur une console. Rebooter n'était pas trop envisageable car plusieurs personnes faisaient tourner des process assez longs sur la machine. Kbd_mode à distance pour remettre le clavier en état a fonctionné.
Autrement il m'est arrivé que les diodes ne répondent plus mais que les touches magiques fonctionnent encore. Dans ce cas un alt-impr_écran-k me rend parfois la console (si noyau compilé avec support de Magic Keys).
Sébastien Kirche
no_spam
On Thu, 25 Nov 2004 14:36:41 +0100, Bruno Patri wrote:
Bruno Patri wrote: [...]
PS : peut-on tester le DD autrement qu'au boot ? Je parle de tester, pas de corriger d'éventuelles erreurs.
Pas sur des partitions montées, il vaut mieux éviter.
Ou les remonter en read-only le temps du fsck...
On Thu, 25 Nov 2004 14:36:41 +0100, Bruno Patri wrote:
Bruno Patri wrote:
[...]
PS : peut-on tester le DD autrement qu'au boot ? Je parle de tester, pas
de corriger d'éventuelles erreurs.
Pas sur des partitions montées, il vaut mieux éviter.
