Le PC sous Debian Woody qui me sert de passerelle internet, firewall, MX
et DNS et donc qui tourne en permanence depuis plus d'un an semble
souffrir de corruptions de fichiers épisodiques. Je m'en rends compte
quand c'est un binaire exécutable est atteint parce qu'il ne fonctionne
plus normalement. C'est arrivé trois fois depuis fin mars 2005.
Coïncidence ou pas, ça a commencé peu après le plantage du système
arrivé pendant un cron-daily que j'avais relaté ici en mi-mars.
La première fois, ce fut telnet qui partait en segfault dès son
lancement. Problème résolu par la réinstallation du paquetage. Ensuite
ce fut un autre binaire, j'ai oublié lequel, mais corrigé de la même
façon. Aujourd'hui c'est au tour d'exim qui coupe la connexion juste
après avoir reçu le saut de ligne qui suit les en-têtes d'un message.
Sans aucun message d'erreur dans les logs, c'est pratique.
Cette fois, plutôt que réinstaller, j'ai comparé les sommes MD5 des
fichiers extraits du .deb d'exim avec celles des fichiers installés.
Résultat : le fichier /usr/sbin/exim diffère. La comparaison par diff
des dumps hexadécimaux des deux fichiers obtenus avec od (il y a
peut-être plus simple mais je ne connais pas) révèle une différence sur
un bit d'un octet.
Le PC n'est plus tout jeune, mais largement suffisant pour
l'application. C'est un desktop Zenith Z-Station EL avec un Pentium 233
MMX, 64 Mo de DRAM EDO et un disque dur de 2,1 Go en ext2. Rien dans les
logs concernant hda, pas d'erreur rapportée par les outils SMART.
Qu'est-ce qui peut provoquer ces corruptions de fichiers qui ne sont pas
censés bouger en dehors des mises à jour ?
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
Nicolas George
"" wrote in message <dac5v4$1h9h$:
(il y a peut-être plus simple mais je ne connais pas)
cmp -l
révèle une différence sur un bit d'un octet.
Très certainement, ta RAM est foireuse. Comme tu vas avoir peut-être du mal à retrouver le bon modèle, le plus simple est probablement d'isoler la page contenant le bit défectueux. Je crois qu'il y a eu quelque chose ici pour expliquer la manoeuvre il y a quelques mois, mais je ne suis pas sûr. Si tu ne trouves pas, j'essaierai de trouver le temps de faire un mini-HOWTO.
Qu'est-ce qui peut provoquer ces corruptions de fichiers qui ne sont pas censés bouger en dehors des mises à jour ?
En fait, le fichier lui-même n'était probablement pas corrompu, seulement son image en cache disque l'était, un reboot (ou une vidange du cache, mais ce n'est jamais évident d'être sûr que tout est parti) aurait corrigé le problème.
"Pascal@plouf" wrote in message <dac5v4$1h9h$1@biggoron.nerim.net>:
(il y a
peut-être plus simple mais je ne connais pas)
cmp -l
révèle une différence sur
un bit d'un octet.
Très certainement, ta RAM est foireuse. Comme tu vas avoir peut-être du mal
à retrouver le bon modèle, le plus simple est probablement d'isoler la page
contenant le bit défectueux. Je crois qu'il y a eu quelque chose ici pour
expliquer la manoeuvre il y a quelques mois, mais je ne suis pas sûr. Si tu
ne trouves pas, j'essaierai de trouver le temps de faire un mini-HOWTO.
Qu'est-ce qui peut provoquer ces corruptions de fichiers qui ne sont pas
censés bouger en dehors des mises à jour ?
En fait, le fichier lui-même n'était probablement pas corrompu, seulement
son image en cache disque l'était, un reboot (ou une vidange du cache, mais
ce n'est jamais évident d'être sûr que tout est parti) aurait corrigé le
problème.
(il y a peut-être plus simple mais je ne connais pas)
cmp -l
révèle une différence sur un bit d'un octet.
Très certainement, ta RAM est foireuse. Comme tu vas avoir peut-être du mal à retrouver le bon modèle, le plus simple est probablement d'isoler la page contenant le bit défectueux. Je crois qu'il y a eu quelque chose ici pour expliquer la manoeuvre il y a quelques mois, mais je ne suis pas sûr. Si tu ne trouves pas, j'essaierai de trouver le temps de faire un mini-HOWTO.
Qu'est-ce qui peut provoquer ces corruptions de fichiers qui ne sont pas censés bouger en dehors des mises à jour ?
En fait, le fichier lui-même n'était probablement pas corrompu, seulement son image en cache disque l'était, un reboot (ou une vidange du cache, mais ce n'est jamais évident d'être sûr que tout est parti) aurait corrigé le problème.
Pascal
[différences entre deux fichiers binaires]
cmp -l
Ah oui, merci, c'est beaucoup plus pratique que od+diff :-)
[erreur d'un bit sur un fichier binaire]
Très certainement, ta RAM est foireuse. Comme tu vas avoir peut-être du mal à retrouver le bon modèle, le plus simple est probablement d'isoler la page contenant le bit défectueux. Je crois qu'il y a eu quelque chose ici pour expliquer la manoeuvre il y a quelques mois, mais je ne suis pas sûr. Si tu ne trouves pas, j'essaierai de trouver le temps de faire un mini-HOWTO.
Merci pour l'info, au besoin je regarderai ça.
Qu'est-ce qui peut provoquer ces corruptions de fichiers qui ne sont pas censés bouger en dehors des mises à jour ?
En fait, le fichier lui-même n'était probablement pas corrompu, seulement son image en cache disque l'était,
Je n'avais pas du tout pensé à ça.
un reboot (ou une vidange du cache, mais ce n'est jamais évident d'être sûr que tout est parti) aurait corrigé le problème.
Comme j'avais conservé (juste renommé) le fichier supposé corrompu, j'ai pu vérifier. Et tu as vu juste, après redémarrage il n'y a plus de différence avec le fichier extrait du .deb. Du coup c'est aussi une erreur mémoire qui a pu causer le crash système de l'autre fois, non ?
Je vais passer un coup de Memtest86 cette nuit pour voir, après tout il faut bien que les MX et DNS secondaires fournis par Nerim servent de temps en temps. ;-) Concernant le remplacement de la RAM EDO, ça va, j'ai une petite réserve de barrettes de récupération.
Merci pour tout !
[différences entre deux fichiers binaires]
cmp -l
Ah oui, merci, c'est beaucoup plus pratique que od+diff :-)
[erreur d'un bit sur un fichier binaire]
Très certainement, ta RAM est foireuse. Comme tu vas avoir peut-être du mal
à retrouver le bon modèle, le plus simple est probablement d'isoler la page
contenant le bit défectueux. Je crois qu'il y a eu quelque chose ici pour
expliquer la manoeuvre il y a quelques mois, mais je ne suis pas sûr. Si tu
ne trouves pas, j'essaierai de trouver le temps de faire un mini-HOWTO.
Merci pour l'info, au besoin je regarderai ça.
Qu'est-ce qui peut provoquer ces corruptions de fichiers qui ne sont pas
censés bouger en dehors des mises à jour ?
En fait, le fichier lui-même n'était probablement pas corrompu, seulement
son image en cache disque l'était,
Je n'avais pas du tout pensé à ça.
un reboot (ou une vidange du cache, mais ce n'est jamais évident d'être
sûr que tout est parti) aurait corrigé le problème.
Comme j'avais conservé (juste renommé) le fichier supposé corrompu, j'ai
pu vérifier. Et tu as vu juste, après redémarrage il n'y a plus de
différence avec le fichier extrait du .deb. Du coup c'est aussi une
erreur mémoire qui a pu causer le crash système de l'autre fois, non ?
Je vais passer un coup de Memtest86 cette nuit pour voir, après tout il
faut bien que les MX et DNS secondaires fournis par Nerim servent de
temps en temps. ;-) Concernant le remplacement de la RAM EDO, ça va,
j'ai une petite réserve de barrettes de récupération.
Ah oui, merci, c'est beaucoup plus pratique que od+diff :-)
[erreur d'un bit sur un fichier binaire]
Très certainement, ta RAM est foireuse. Comme tu vas avoir peut-être du mal à retrouver le bon modèle, le plus simple est probablement d'isoler la page contenant le bit défectueux. Je crois qu'il y a eu quelque chose ici pour expliquer la manoeuvre il y a quelques mois, mais je ne suis pas sûr. Si tu ne trouves pas, j'essaierai de trouver le temps de faire un mini-HOWTO.
Merci pour l'info, au besoin je regarderai ça.
Qu'est-ce qui peut provoquer ces corruptions de fichiers qui ne sont pas censés bouger en dehors des mises à jour ?
En fait, le fichier lui-même n'était probablement pas corrompu, seulement son image en cache disque l'était,
Je n'avais pas du tout pensé à ça.
un reboot (ou une vidange du cache, mais ce n'est jamais évident d'être sûr que tout est parti) aurait corrigé le problème.
Comme j'avais conservé (juste renommé) le fichier supposé corrompu, j'ai pu vérifier. Et tu as vu juste, après redémarrage il n'y a plus de différence avec le fichier extrait du .deb. Du coup c'est aussi une erreur mémoire qui a pu causer le crash système de l'autre fois, non ?
Je vais passer un coup de Memtest86 cette nuit pour voir, après tout il faut bien que les MX et DNS secondaires fournis par Nerim servent de temps en temps. ;-) Concernant le remplacement de la RAM EDO, ça va, j'ai une petite réserve de barrettes de récupération.
Merci pour tout !
Michel Tatoute
wrote:
Très certainement, ta RAM est foireuse. Merci pour tout !
Moi aussi je dis merci car j'ai eu un pb exactement similaire (mais plus grave, c'était un .so critique qui plantait), disparu après reboot.
je vais verifier la ram moi aussi.
Michel.
Pascal@plouf wrote:
Très certainement, ta RAM est foireuse.
Merci pour tout !
Moi aussi je dis merci car j'ai eu un pb exactement similaire (mais plus
grave, c'était un .so critique qui plantait), disparu après reboot.
Je vais passer un coup de Memtest86 cette nuit pour voir
Après 33 passes de test standard, Memtest86 n'a détecté aucune erreur. :- Je lancerai les tests avancés la nuit prochaine...
Nicolas George
"" wrote in message <dad8mb$1spp$:
Après 33 passes de test standard, Memtest86 n'a détecté aucune erreur.
C'est assez classique, avec memtest86. En particulier, si le bit met longtemps à perdre sa valeur, il sera systématiquement raté.
Tu peux essayer urumt <URL: http://www.eleves.ens.fr/home/george/info/prg/rumt.html >, qui fonctionne sur un système en route, en allouant un glos bloc de mémoire, en le remplissant de données, et en relisant plus tard les données pour vérifier qu'elles sont valides.
"Pascal@plouf" wrote in message <dad8mb$1spp$1@biggoron.nerim.net>:
Après 33 passes de test standard, Memtest86 n'a détecté aucune erreur.
C'est assez classique, avec memtest86. En particulier, si le bit met
longtemps à perdre sa valeur, il sera systématiquement raté.
Tu peux essayer urumt <URL:
http://www.eleves.ens.fr/home/george/info/prg/rumt.html >, qui fonctionne
sur un système en route, en allouant un glos bloc de mémoire, en le
remplissant de données, et en relisant plus tard les données pour vérifier
qu'elles sont valides.
Après 33 passes de test standard, Memtest86 n'a détecté aucune erreur.
C'est assez classique, avec memtest86. En particulier, si le bit met longtemps à perdre sa valeur, il sera systématiquement raté.
Tu peux essayer urumt <URL: http://www.eleves.ens.fr/home/george/info/prg/rumt.html >, qui fonctionne sur un système en route, en allouant un glos bloc de mémoire, en le remplissant de données, et en relisant plus tard les données pour vérifier qu'elles sont valides.
l'indien
On Tue, 05 Jul 2005 12:07:45 +0000, Nicolas George wrote:
"" wrote in message <dad8mb$1spp$:
Après 33 passes de test standard, Memtest86 n'a détecté aucune erreur.
C'est assez classique, avec memtest86. En particulier, si le bit met longtemps à perdre sa valeur, il sera systématiquement raté.
Tu peux essayer urumt <URL: http://www.eleves.ens.fr/home/george/info/prg/rumt.html >, qui fonctionne sur un système en route, en allouant un glos bloc de mémoire, en le remplissant de données, et en relisant plus tard les données pour vérifier qu'elles sont valides.
memtest86 a aussi des tests de relaxation mémoire. Il suffit de les activer. Dans ce cas, il attends 90 minutes entre l'écriture des pattern et la relecture, ce qui suffit généralement pour voir ce genre de problèmes.
On Tue, 05 Jul 2005 12:07:45 +0000, Nicolas George wrote:
"Pascal@plouf" wrote in message <dad8mb$1spp$1@biggoron.nerim.net>:
Après 33 passes de test standard, Memtest86 n'a détecté aucune erreur.
C'est assez classique, avec memtest86. En particulier, si le bit met
longtemps à perdre sa valeur, il sera systématiquement raté.
Tu peux essayer urumt <URL:
http://www.eleves.ens.fr/home/george/info/prg/rumt.html >, qui fonctionne
sur un système en route, en allouant un glos bloc de mémoire, en le
remplissant de données, et en relisant plus tard les données pour vérifier
qu'elles sont valides.
memtest86 a aussi des tests de relaxation mémoire.
Il suffit de les activer. Dans ce cas, il attends 90 minutes entre
l'écriture des pattern et la relecture, ce qui suffit généralement pour
voir ce genre de problèmes.
On Tue, 05 Jul 2005 12:07:45 +0000, Nicolas George wrote:
"" wrote in message <dad8mb$1spp$:
Après 33 passes de test standard, Memtest86 n'a détecté aucune erreur.
C'est assez classique, avec memtest86. En particulier, si le bit met longtemps à perdre sa valeur, il sera systématiquement raté.
Tu peux essayer urumt <URL: http://www.eleves.ens.fr/home/george/info/prg/rumt.html >, qui fonctionne sur un système en route, en allouant un glos bloc de mémoire, en le remplissant de données, et en relisant plus tard les données pour vérifier qu'elles sont valides.
memtest86 a aussi des tests de relaxation mémoire. Il suffit de les activer. Dans ce cas, il attends 90 minutes entre l'écriture des pattern et la relecture, ce qui suffit généralement pour voir ce genre de problèmes.
Pascal
On Tue, 05 Jul 2005 12:07:45 +0000, Nicolas George wrote:
Après 33 passes de test standard, Memtest86 n'a détecté aucune erreur.
C'est assez classique, avec memtest86. En particulier, si le bit met longtemps à perdre sa valeur, il sera systématiquement raté.
C'est bien ce que je me suis dit.
Tu peux essayer urumt <URL: http://www.eleves.ens.fr/home/george/info/prg/rumt.html >, qui fonctionne sur un système en route, en allouant un glos bloc de mémoire, en le remplissant de données, et en relisant plus tard les données pour vérifier qu'elles sont valides.
Je ne dois pas être doué, je n'ai pas trouvé comment faire cela avec urumt. :-
memtest86 a aussi des tests de relaxation mémoire. Il suffit de les activer. Dans ce cas, il attends 90 minutes entre l'écriture des pattern et la relecture, ce qui suffit généralement pour voir ce genre de problèmes.
Ah, voilà une nouveauté qui n'existait pas encore dans la version 3.0 dont je disposais. J'essaierai cette nuit avec la 3.2.
Merci à tous les deux.
On Tue, 05 Jul 2005 12:07:45 +0000, Nicolas George wrote:
Après 33 passes de test standard, Memtest86 n'a détecté aucune erreur.
C'est assez classique, avec memtest86. En particulier, si le bit met
longtemps à perdre sa valeur, il sera systématiquement raté.
C'est bien ce que je me suis dit.
Tu peux essayer urumt <URL:
http://www.eleves.ens.fr/home/george/info/prg/rumt.html >, qui fonctionne
sur un système en route, en allouant un glos bloc de mémoire, en le
remplissant de données, et en relisant plus tard les données pour vérifier
qu'elles sont valides.
Je ne dois pas être doué, je n'ai pas trouvé comment faire cela avec
urumt. :-
memtest86 a aussi des tests de relaxation mémoire.
Il suffit de les activer. Dans ce cas, il attends 90 minutes entre
l'écriture des pattern et la relecture, ce qui suffit généralement pour
voir ce genre de problèmes.
Ah, voilà une nouveauté qui n'existait pas encore dans la version 3.0
dont je disposais. J'essaierai cette nuit avec la 3.2.
On Tue, 05 Jul 2005 12:07:45 +0000, Nicolas George wrote:
Après 33 passes de test standard, Memtest86 n'a détecté aucune erreur.
C'est assez classique, avec memtest86. En particulier, si le bit met longtemps à perdre sa valeur, il sera systématiquement raté.
C'est bien ce que je me suis dit.
Tu peux essayer urumt <URL: http://www.eleves.ens.fr/home/george/info/prg/rumt.html >, qui fonctionne sur un système en route, en allouant un glos bloc de mémoire, en le remplissant de données, et en relisant plus tard les données pour vérifier qu'elles sont valides.
Je ne dois pas être doué, je n'ai pas trouvé comment faire cela avec urumt. :-
memtest86 a aussi des tests de relaxation mémoire. Il suffit de les activer. Dans ce cas, il attends 90 minutes entre l'écriture des pattern et la relecture, ce qui suffit généralement pour voir ce genre de problèmes.
Ah, voilà une nouveauté qui n'existait pas encore dans la version 3.0 dont je disposais. J'essaierai cette nuit avec la 3.2.
Merci à tous les deux.
Pascal
memtest86 a aussi des tests de relaxation mémoire. Il suffit de les activer. Dans ce cas, il attends 90 minutes entre l'écriture des pattern et la relecture, ce qui suffit généralement pour voir ce genre de problèmes.
Ah, voilà une nouveauté qui n'existait pas encore dans la version 3.0 dont je disposais. J'essaierai cette nuit avec la 3.2.
Voilà, j'ai lancé le test "bit fade" de Memtest 3.2 mais il n'a rien trouvé. Je vais me résoudre à remplacer les barrettes de RAM en espérant que le problème ne vient pas d'ailleurs.
memtest86 a aussi des tests de relaxation mémoire.
Il suffit de les activer. Dans ce cas, il attends 90 minutes entre
l'écriture des pattern et la relecture, ce qui suffit généralement pour
voir ce genre de problèmes.
Ah, voilà une nouveauté qui n'existait pas encore dans la version 3.0
dont je disposais. J'essaierai cette nuit avec la 3.2.
Voilà, j'ai lancé le test "bit fade" de Memtest 3.2 mais il n'a rien
trouvé. Je vais me résoudre à remplacer les barrettes de RAM en espérant
que le problème ne vient pas d'ailleurs.
memtest86 a aussi des tests de relaxation mémoire. Il suffit de les activer. Dans ce cas, il attends 90 minutes entre l'écriture des pattern et la relecture, ce qui suffit généralement pour voir ce genre de problèmes.
Ah, voilà une nouveauté qui n'existait pas encore dans la version 3.0 dont je disposais. J'essaierai cette nuit avec la 3.2.
Voilà, j'ai lancé le test "bit fade" de Memtest 3.2 mais il n'a rien trouvé. Je vais me résoudre à remplacer les barrettes de RAM en espérant que le problème ne vient pas d'ailleurs.
