Bonjour, depuis plusieurs semaines il m'arrive un truc vraiment
désagréable et qui j'espère ne finira pas par me poser des problèmes
(corruption du filesystem) : mon serveur se gèle régulièrement, sans que
rien n'apparaisse dans les logs.
Je sais que dans un cas comme ça on commence par soupçonner le hardware
et faire un test mémoire. Mais il y a un indice supplémentaire, les
freezes se produisent TOUJOURS lors mldonkey (client emule) est lancé.
Avant de commencer à changer les barettes (oui j'ai eu UNE fois, UNE
erreur lors d'une passe (sur un test qui en a comporté une dizaine) mais
je doute que ce soit en rapport, sinon j'aurais les même problème
lorsque mldonkey ne fonctionne pas)
J'aimerais donc savoir s'il y a un moyen de mettre un process sous
"surveillance" ? La conso mémoire ne semble pas être en cause (en tout
cas la commande top ne me montre pas une augmentation régulière et
anormale de l'espace mémoire)
A un moment j'avais pensé que ça pouvait venir d'une de mes carte
ethernet (j'en ai deux) car lorsque le débit réseau augmentait (accès
soutenu en transfert de fichier par samba). J'ai supprimé la carte sur
laquelle est le réseau local et activé le controleur ethernet de la
carte mère, sans succès. Peut-être devrais-je remplacer la carte
ethernet surlaquelle transite le flux sortant (vers ma freebox).
Je suis sous Redhat 9.
A toute fin utile, voici les process qui tournent sur cette machine (en
dehors de mldonkey)
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
Emmanuel Fleury
Zouplaz wrote:
Bonjour, depuis plusieurs semaines il m'arrive un truc vraiment désagréable et qui j'espère ne finira pas par me poser des problèmes (corruption du filesystem) : mon serveur se gèle régulièrement, sans que rien n'apparaisse dans les logs.
Que dis le /var/log/messages ?
Si tu n'y trouve rien, compile un noyau avec les options de kernel debugging et avec les magic-keys (voir linux-2.6.14.1/Documentation/sysrq.txt) et si ta machine replante, note le Oops qui sera affiché.
Sans ce message d'erreur on ne peut pas faire grand chose pour toi.
PS: À tout hasard fait un memcheck de ta RAM et vérifie l'intégrité de ton système de fichiers avec fsck.
Amicalement -- Emmanuel Fleury
Real computer scientists despise the idea of actual hardware. Hardware has limitations, software doesn't. It's a real shame that Turing machines are so poor at I/O. -- Unknown
Zouplaz wrote:
Bonjour, depuis plusieurs semaines il m'arrive un truc vraiment
désagréable et qui j'espère ne finira pas par me poser des problèmes
(corruption du filesystem) : mon serveur se gèle régulièrement, sans que
rien n'apparaisse dans les logs.
Que dis le /var/log/messages ?
Si tu n'y trouve rien, compile un noyau avec les options de kernel
debugging et avec les magic-keys (voir
linux-2.6.14.1/Documentation/sysrq.txt) et si ta machine replante, note
le Oops qui sera affiché.
Sans ce message d'erreur on ne peut pas faire grand chose pour toi.
PS: À tout hasard fait un memcheck de ta RAM et vérifie l'intégrité de
ton système de fichiers avec fsck.
Amicalement
--
Emmanuel Fleury
Real computer scientists despise the idea of actual hardware.
Hardware has limitations, software doesn't.
It's a real shame that Turing machines are so poor at I/O.
-- Unknown
Bonjour, depuis plusieurs semaines il m'arrive un truc vraiment désagréable et qui j'espère ne finira pas par me poser des problèmes (corruption du filesystem) : mon serveur se gèle régulièrement, sans que rien n'apparaisse dans les logs.
Que dis le /var/log/messages ?
Si tu n'y trouve rien, compile un noyau avec les options de kernel debugging et avec les magic-keys (voir linux-2.6.14.1/Documentation/sysrq.txt) et si ta machine replante, note le Oops qui sera affiché.
Sans ce message d'erreur on ne peut pas faire grand chose pour toi.
PS: À tout hasard fait un memcheck de ta RAM et vérifie l'intégrité de ton système de fichiers avec fsck.
Amicalement -- Emmanuel Fleury
Real computer scientists despise the idea of actual hardware. Hardware has limitations, software doesn't. It's a real shame that Turing machines are so poor at I/O. -- Unknown
Zouplaz
Emmanuel Fleury wrote:
Zouplaz wrote:
Bonjour, depuis plusieurs semaines il m'arrive un truc vraiment désagréable et qui j'espère ne finira pas par me poser des problèmes (corruption du filesystem) : mon serveur se gèle régulièrement, sans que rien n'apparaisse dans les logs.
Que dis le /var/log/messages ?
Si tu n'y trouve rien, compile un noyau avec les options de kernel debugging et avec les magic-keys (voir linux-2.6.14.1/Documentation/sysrq.txt) et si ta machine replante, note le Oops qui sera affiché.
Sans ce message d'erreur on ne peut pas faire grand chose pour toi.
PS: À tout hasard fait un memcheck de ta RAM et vérifie l'intégrité de ton système de fichiers avec fsck.
Amicalement
Merci pour ces conseils, je vais recompiler le kernel comme tu le précises (j'ai tenté d'upgrader jusqu'à la dernière 2.4 mais ça n'a rien changé). Ca devrait m'aider !
Pour le fsck, il est effectué en totalité après chaque crash (au reboot) donc pas de soucis de ce côté là.
Emmanuel Fleury wrote:
Zouplaz wrote:
Bonjour, depuis plusieurs semaines il m'arrive un truc vraiment
désagréable et qui j'espère ne finira pas par me poser des problèmes
(corruption du filesystem) : mon serveur se gèle régulièrement, sans que
rien n'apparaisse dans les logs.
Que dis le /var/log/messages ?
Si tu n'y trouve rien, compile un noyau avec les options de kernel
debugging et avec les magic-keys (voir
linux-2.6.14.1/Documentation/sysrq.txt) et si ta machine replante, note
le Oops qui sera affiché.
Sans ce message d'erreur on ne peut pas faire grand chose pour toi.
PS: À tout hasard fait un memcheck de ta RAM et vérifie l'intégrité de
ton système de fichiers avec fsck.
Amicalement
Merci pour ces conseils, je vais recompiler le kernel comme tu le
précises (j'ai tenté d'upgrader jusqu'à la dernière 2.4 mais ça n'a rien
changé). Ca devrait m'aider !
Pour le fsck, il est effectué en totalité après chaque crash (au reboot)
donc pas de soucis de ce côté là.
Bonjour, depuis plusieurs semaines il m'arrive un truc vraiment désagréable et qui j'espère ne finira pas par me poser des problèmes (corruption du filesystem) : mon serveur se gèle régulièrement, sans que rien n'apparaisse dans les logs.
Que dis le /var/log/messages ?
Si tu n'y trouve rien, compile un noyau avec les options de kernel debugging et avec les magic-keys (voir linux-2.6.14.1/Documentation/sysrq.txt) et si ta machine replante, note le Oops qui sera affiché.
Sans ce message d'erreur on ne peut pas faire grand chose pour toi.
PS: À tout hasard fait un memcheck de ta RAM et vérifie l'intégrité de ton système de fichiers avec fsck.
Amicalement
Merci pour ces conseils, je vais recompiler le kernel comme tu le précises (j'ai tenté d'upgrader jusqu'à la dernière 2.4 mais ça n'a rien changé). Ca devrait m'aider !
Pour le fsck, il est effectué en totalité après chaque crash (au reboot) donc pas de soucis de ce côté là.
Christophe PEREZ
Le Fri, 25 Nov 2005 09:34:40 +0100, Zouplaz a écrit:
Je suis preneur de vos avis éclairés !! Merci
Par pur hasard complet, tu n'aurais pas un modem avec driver linuxant qui tourne ? Un lsmod nous aurait aussi montré les modules chargés.
Je dis ça, tout simplement parce que j'ai longtemps eu des plantages de mon serveur, uniquement dus au fait que j'utilisais le driver beta (le seul gratuit). Du jour où j'ai payé pour le driver à jour, je n'ai plus eu ces plantages. Bon, depuis, j'ai changé de serveur, et donc de modem.
Et la GUI de mldonkey tourne au moment des plantages ? Parce que elle, elle est (était, à l'époque) particulièrement gourmande, et pas nécessairement stable.
-- Christophe PEREZ Écrivez moi sans _faute !
Le Fri, 25 Nov 2005 09:34:40 +0100, Zouplaz a écrit:
Je suis preneur de vos avis éclairés !! Merci
Par pur hasard complet, tu n'aurais pas un modem avec driver linuxant qui
tourne ?
Un lsmod nous aurait aussi montré les modules chargés.
Je dis ça, tout simplement parce que j'ai longtemps eu des plantages de
mon serveur, uniquement dus au fait que j'utilisais le driver beta (le
seul gratuit). Du jour où j'ai payé pour le driver à jour, je n'ai plus
eu ces plantages.
Bon, depuis, j'ai changé de serveur, et donc de modem.
Et la GUI de mldonkey tourne au moment des plantages ?
Parce que elle, elle est (était, à l'époque) particulièrement gourmande,
et pas nécessairement stable.
Le Fri, 25 Nov 2005 09:34:40 +0100, Zouplaz a écrit:
Je suis preneur de vos avis éclairés !! Merci
Par pur hasard complet, tu n'aurais pas un modem avec driver linuxant qui tourne ? Un lsmod nous aurait aussi montré les modules chargés.
Je dis ça, tout simplement parce que j'ai longtemps eu des plantages de mon serveur, uniquement dus au fait que j'utilisais le driver beta (le seul gratuit). Du jour où j'ai payé pour le driver à jour, je n'ai plus eu ces plantages. Bon, depuis, j'ai changé de serveur, et donc de modem.
Et la GUI de mldonkey tourne au moment des plantages ? Parce que elle, elle est (était, à l'époque) particulièrement gourmande, et pas nécessairement stable.
-- Christophe PEREZ Écrivez moi sans _faute !
Zouplaz
Christophe PEREZ wrote:
Par pur hasard complet, tu n'aurais pas un modem avec driver linuxant qui tourne ? Un lsmod nous aurait aussi montré les modules chargés.
Je dis ça, tout simplement parce que j'ai longtemps eu des plantages de mon serveur, uniquement dus au fait que j'utilisais le driver beta (le seul gratuit). Du jour où j'ai payé pour le driver à jour, je n'ai plus eu ces plantages. Bon, depuis, j'ai changé de serveur, et donc de modem.
Non, pas de modem ou de driver spécifique et aucun patch du noyau...
Serveur de dev ;-) Je laisserais pas tourner X sinon - Pis quand même j'ai quelques règles iptables.
Et la GUI de mldonkey tourne au moment des plantages ? Parce que elle, elle est (était, à l'époque) particulièrement gourmande, et pas nécessairement stable.
Non, je me sert d'un navigateur web à partir d'un autre poste du réseau. J'ai jamais utilisé de gui pour mldonkey.
Christophe PEREZ wrote:
Par pur hasard complet, tu n'aurais pas un modem avec driver linuxant qui
tourne ?
Un lsmod nous aurait aussi montré les modules chargés.
Je dis ça, tout simplement parce que j'ai longtemps eu des plantages de
mon serveur, uniquement dus au fait que j'utilisais le driver beta (le
seul gratuit). Du jour où j'ai payé pour le driver à jour, je n'ai plus
eu ces plantages.
Bon, depuis, j'ai changé de serveur, et donc de modem.
Non, pas de modem ou de driver spécifique et aucun patch du noyau...
Serveur de dev ;-) Je laisserais pas tourner X sinon - Pis quand même
j'ai quelques règles iptables.
Et la GUI de mldonkey tourne au moment des plantages ?
Parce que elle, elle est (était, à l'époque) particulièrement gourmande,
et pas nécessairement stable.
Non, je me sert d'un navigateur web à partir d'un autre poste du réseau.
J'ai jamais utilisé de gui pour mldonkey.
Par pur hasard complet, tu n'aurais pas un modem avec driver linuxant qui tourne ? Un lsmod nous aurait aussi montré les modules chargés.
Je dis ça, tout simplement parce que j'ai longtemps eu des plantages de mon serveur, uniquement dus au fait que j'utilisais le driver beta (le seul gratuit). Du jour où j'ai payé pour le driver à jour, je n'ai plus eu ces plantages. Bon, depuis, j'ai changé de serveur, et donc de modem.
Non, pas de modem ou de driver spécifique et aucun patch du noyau...
Serveur de dev ;-) Je laisserais pas tourner X sinon - Pis quand même j'ai quelques règles iptables.
Et la GUI de mldonkey tourne au moment des plantages ? Parce que elle, elle est (était, à l'époque) particulièrement gourmande, et pas nécessairement stable.
Non, je me sert d'un navigateur web à partir d'un autre poste du réseau. J'ai jamais utilisé de gui pour mldonkey.
Zouplaz
Emmanuel Fleury wrote:
Si tu n'y trouve rien, compile un noyau avec les options de kernel debugging et avec les magic-keys (voir linux-2.6.14.1/Documentation/sysrq.txt) et si ta machine replante, note le Oops qui sera affiché.
J'ai donc tenté, et activé presque toutes les options de debugging. Ca tourne pas plus lentement qu'avant par contre ça fait deux jours que je le maltraite et il n'a pas planté (dans des circonstances où ça n'aurait pas manqué d'arriver).
Parmi les options il y avait celles concernant la mémoire (vérification stack, parité, et je sais plus quoi)
Par contre, toujours rien dans les logs -
Emmanuel Fleury wrote:
Si tu n'y trouve rien, compile un noyau avec les options de kernel
debugging et avec les magic-keys (voir
linux-2.6.14.1/Documentation/sysrq.txt) et si ta machine replante, note
le Oops qui sera affiché.
J'ai donc tenté, et activé presque toutes les options de debugging. Ca
tourne pas plus lentement qu'avant par contre ça fait deux jours que je
le maltraite et il n'a pas planté (dans des circonstances où ça n'aurait
pas manqué d'arriver).
Parmi les options il y avait celles concernant la mémoire (vérification
stack, parité, et je sais plus quoi)
Si tu n'y trouve rien, compile un noyau avec les options de kernel debugging et avec les magic-keys (voir linux-2.6.14.1/Documentation/sysrq.txt) et si ta machine replante, note le Oops qui sera affiché.
J'ai donc tenté, et activé presque toutes les options de debugging. Ca tourne pas plus lentement qu'avant par contre ça fait deux jours que je le maltraite et il n'a pas planté (dans des circonstances où ça n'aurait pas manqué d'arriver).
Parmi les options il y avait celles concernant la mémoire (vérification stack, parité, et je sais plus quoi)
Par contre, toujours rien dans les logs -
Emmanuel Fleury
Zouplaz wrote:
J'ai donc tenté, et activé presque toutes les options de debugging. Ca tourne pas plus lentement qu'avant
Les mécanismes que tu ajoutes au noyau n'interviennent qu'en cas de crash, pas lors du fonctionnement normal du système. C'est pour cela que tu n'observes pas de ralentissement (cela dit, il doit y avoir un petit ralentissement, mais tu ne peux pas le percevoir).
par contre ça fait deux jours que je le maltraite et il n'a pas planté (dans des circonstances où ça n'aurait pas manqué d'arriver).
Tant mieux ! :)
Parmi les options il y avait celles concernant la mémoire (vérification stack, parité, et je sais plus quoi)
Lorsqu'une des conditions sera violée, tu aura un log, mais en attendant...
Certains bugs sont très long à trouver (et pas évident). Par exemple, celui-ci m'a demandé environs un an: http://www.cs.aau.dk/~fleury/bug_cms/
Il faut persister et ne pas se décourager et ne pas assumer des choses qui n'existent pas.
Amicalement -- Emmanuel Fleury
The great difficulty in debugging: You have to divorce yourself from preconceptions, make your mind blank, unlinked, unchanneld, the Zen state ... -- Ellen Ullman (The Bug)
Zouplaz wrote:
J'ai donc tenté, et activé presque toutes les options de debugging. Ca
tourne pas plus lentement qu'avant
Les mécanismes que tu ajoutes au noyau n'interviennent qu'en cas de
crash, pas lors du fonctionnement normal du système. C'est pour cela que
tu n'observes pas de ralentissement (cela dit, il doit y avoir un petit
ralentissement, mais tu ne peux pas le percevoir).
par contre ça fait deux jours que je
le maltraite et il n'a pas planté (dans des circonstances où ça n'aurait
pas manqué d'arriver).
Tant mieux ! :)
Parmi les options il y avait celles concernant la mémoire (vérification
stack, parité, et je sais plus quoi)
Lorsqu'une des conditions sera violée, tu aura un log, mais en attendant...
Certains bugs sont très long à trouver (et pas évident). Par exemple,
celui-ci m'a demandé environs un an: http://www.cs.aau.dk/~fleury/bug_cms/
Il faut persister et ne pas se décourager et ne pas assumer des choses
qui n'existent pas.
Amicalement
--
Emmanuel Fleury
The great difficulty in debugging: You have to divorce yourself
from preconceptions, make your mind blank, unlinked, unchanneld,
the Zen state ...
-- Ellen Ullman (The Bug)
J'ai donc tenté, et activé presque toutes les options de debugging. Ca tourne pas plus lentement qu'avant
Les mécanismes que tu ajoutes au noyau n'interviennent qu'en cas de crash, pas lors du fonctionnement normal du système. C'est pour cela que tu n'observes pas de ralentissement (cela dit, il doit y avoir un petit ralentissement, mais tu ne peux pas le percevoir).
par contre ça fait deux jours que je le maltraite et il n'a pas planté (dans des circonstances où ça n'aurait pas manqué d'arriver).
Tant mieux ! :)
Parmi les options il y avait celles concernant la mémoire (vérification stack, parité, et je sais plus quoi)
Lorsqu'une des conditions sera violée, tu aura un log, mais en attendant...
Certains bugs sont très long à trouver (et pas évident). Par exemple, celui-ci m'a demandé environs un an: http://www.cs.aau.dk/~fleury/bug_cms/
Il faut persister et ne pas se décourager et ne pas assumer des choses qui n'existent pas.
Amicalement -- Emmanuel Fleury
The great difficulty in debugging: You have to divorce yourself from preconceptions, make your mind blank, unlinked, unchanneld, the Zen state ... -- Ellen Ullman (The Bug)
