Etonnant, ce matin, je reçois:
[quote]Erreur:: /usr/bin/perl modified
Erreur:: /usr/bin/perl5.8.4 modified
2 modified files[/quote]
de la part de mon programme de surveillance. Cela arrive assez rarement
pour un fichier (inversion spontané de bits) mais sur deux fichiers,
c'est carrément rarissime, Ces deux fichiers doivent être cote à cote
sur le disque je pense pour expliquer cela. J'ai quand même réinstallé
le paquet perl-base auxquels ils appartiennent et fait un checkup de la
machine (sansrésultats) (c'est le parefeu). A votre connaissance,
y-a-t-il un rootkit qui ne modifierait que perl (personnellement je
suis assez tranquille mais bon je pose la question au cas où...)
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le samedi 27 janvier 2007, François Boisson a écrit :
Etonnant, ce matin, je reçois: [quote]Erreur:: /usr/bin/perl modified Erreur:: /usr/bin/perl5.8.4 modified 2 modified files[/quote] de la part de mon programme de surveillance. Cela arrive assez rarement pour un fichier (inversion spontané de bits) mais sur deux fichiers, c'est carrément rarissime, Ces deux fichiers doivent être cote à co te sur le disque je pense pour expliquer cela. J'ai quand même réinstall é le paquet perl-base auxquels ils appartiennent et fait un checkup de la machine (sansrésultats) (c'est le parefeu). A votre connaissance, y-a-t-il un rootkit qui ne modifierait que perl (personnellement je suis assez tranquille mais bon je pose la question au cas où...)
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le samedi 27 janvier 2007, François Boisson a écrit :
Etonnant, ce matin, je reçois:
[quote]Erreur:: /usr/bin/perl modified
Erreur:: /usr/bin/perl5.8.4 modified
2 modified files[/quote]
de la part de mon programme de surveillance. Cela arrive assez rarement
pour un fichier (inversion spontané de bits) mais sur deux fichiers,
c'est carrément rarissime, Ces deux fichiers doivent être cote à co te
sur le disque je pense pour expliquer cela. J'ai quand même réinstall é
le paquet perl-base auxquels ils appartiennent et fait un checkup de la
machine (sansrésultats) (c'est le parefeu). A votre connaissance,
y-a-t-il un rootkit qui ne modifierait que perl (personnellement je
suis assez tranquille mais bon je pose la question au cas où...)
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le samedi 27 janvier 2007, François Boisson a écrit :
Etonnant, ce matin, je reçois: [quote]Erreur:: /usr/bin/perl modified Erreur:: /usr/bin/perl5.8.4 modified 2 modified files[/quote] de la part de mon programme de surveillance. Cela arrive assez rarement pour un fichier (inversion spontané de bits) mais sur deux fichiers, c'est carrément rarissime, Ces deux fichiers doivent être cote à co te sur le disque je pense pour expliquer cela. J'ai quand même réinstall é le paquet perl-base auxquels ils appartiennent et fait un checkup de la machine (sansrésultats) (c'est le parefeu). A votre connaissance, y-a-t-il un rootkit qui ne modifierait que perl (personnellement je suis assez tranquille mais bon je pose la question au cas où...)
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Sylvain Sauvage
François Boisson, samedi 27 janvier 2007, 15:17:41 CET
Etonnant, ce matin, je reçois: [quote]Erreur:: /usr/bin/perl modified Erreur:: /usr/bin/perl5.8.4 modified 2 modified files[/quote]
Certainement /usr/bin/perl est un lien vers /usr/bin/perl5.8.4. Dans ce cas un seul fichier a été modifié.
-- Arnaud
Pascal Hambourg
Salut,
François Boisson a écrit :
Etonnant, ce matin, je reçois: [quote]Erreur:: /usr/bin/perl modified Erreur:: /usr/bin/perl5.8.4 modified 2 modified files[/quote] de la part de mon programme de surveillance. Cela arrive assez rarement pour un fichier (inversion spontané de bits) mais sur deux fichiers, c'est carrément rarissime, Ces deux fichiers doivent être cote à cote sur le disque je pense pour expliquer cela. J'ai quand même réinstallé le paquet perl-base auxquels ils appartiennent et fait un checkup de la machine (sansrésultats) (c'est le parefeu). A votre connaissance, y-a-t-il un rootkit qui ne modifierait que perl (personnellement je suis assez tranquille mais bon je pose la question au cas où...)
Comme souligné par d'autres, c'est le même fichier (inode). J'ai une vieille machine allumée en permanence qui me fait ce genre de chose "régulièrement" (genre une fois tous les six mois) : un fichier, souvent exécutable, se corrompt du jour au lendemain, et génère un segfault ou un message d'erreur. D'ailleurs j'ai eu le cas avec perl dernièrement : un script perl de dpkg exécuté par cron générait un segfault, mais pas d'autres scripts perl. Le fichier corrompu n'était pas /usr/bin/perl (je l'ai comparé avec celui extrait du .deb) mais un autre que je n'ai pas réussi à identifier, peut-être une bibliothèque. En fait à chaque fois c'est seulement l'image du fichier dans le cache disque en mémoire vive qui est corrompue, le fichier lui-même sur le disque est intact. Comme je ne sais pas comment purger un fichier du cache afin qu'il soit rechargé depuis le disque, je redémarre la machine et tout rentre dans l'ordre, jusqu'à la prochaine inversion de bit en mémoire. Pourtant j'ai testé la RAM plusieurs fois avec memtest86 qui ne signale aucune erreur. En fait je crains qu'il ne soit pas prévu pour détecter ce genre d'erreur, où un bit non modifié change d'état spontanément.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Salut,
François Boisson a écrit :
Etonnant, ce matin, je reçois:
[quote]Erreur:: /usr/bin/perl modified
Erreur:: /usr/bin/perl5.8.4 modified
2 modified files[/quote]
de la part de mon programme de surveillance. Cela arrive assez rarement
pour un fichier (inversion spontané de bits) mais sur deux fichiers,
c'est carrément rarissime, Ces deux fichiers doivent être cote à cote
sur le disque je pense pour expliquer cela. J'ai quand même réinstallé
le paquet perl-base auxquels ils appartiennent et fait un checkup de la
machine (sansrésultats) (c'est le parefeu). A votre connaissance,
y-a-t-il un rootkit qui ne modifierait que perl (personnellement je
suis assez tranquille mais bon je pose la question au cas où...)
Comme souligné par d'autres, c'est le même fichier (inode). J'ai une
vieille machine allumée en permanence qui me fait ce genre de chose
"régulièrement" (genre une fois tous les six mois) : un fichier, souvent
exécutable, se corrompt du jour au lendemain, et génère un segfault ou
un message d'erreur. D'ailleurs j'ai eu le cas avec perl dernièrement :
un script perl de dpkg exécuté par cron générait un segfault, mais pas
d'autres scripts perl. Le fichier corrompu n'était pas /usr/bin/perl (je
l'ai comparé avec celui extrait du .deb) mais un autre que je n'ai pas
réussi à identifier, peut-être une bibliothèque. En fait à chaque fois
c'est seulement l'image du fichier dans le cache disque en mémoire vive
qui est corrompue, le fichier lui-même sur le disque est intact. Comme
je ne sais pas comment purger un fichier du cache afin qu'il soit
rechargé depuis le disque, je redémarre la machine et tout rentre dans
l'ordre, jusqu'à la prochaine inversion de bit en mémoire. Pourtant j'ai
testé la RAM plusieurs fois avec memtest86 qui ne signale aucune erreur.
En fait je crains qu'il ne soit pas prévu pour détecter ce genre
d'erreur, où un bit non modifié change d'état spontanément.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Etonnant, ce matin, je reçois: [quote]Erreur:: /usr/bin/perl modified Erreur:: /usr/bin/perl5.8.4 modified 2 modified files[/quote] de la part de mon programme de surveillance. Cela arrive assez rarement pour un fichier (inversion spontané de bits) mais sur deux fichiers, c'est carrément rarissime, Ces deux fichiers doivent être cote à cote sur le disque je pense pour expliquer cela. J'ai quand même réinstallé le paquet perl-base auxquels ils appartiennent et fait un checkup de la machine (sansrésultats) (c'est le parefeu). A votre connaissance, y-a-t-il un rootkit qui ne modifierait que perl (personnellement je suis assez tranquille mais bon je pose la question au cas où...)
Comme souligné par d'autres, c'est le même fichier (inode). J'ai une vieille machine allumée en permanence qui me fait ce genre de chose "régulièrement" (genre une fois tous les six mois) : un fichier, souvent exécutable, se corrompt du jour au lendemain, et génère un segfault ou un message d'erreur. D'ailleurs j'ai eu le cas avec perl dernièrement : un script perl de dpkg exécuté par cron générait un segfault, mais pas d'autres scripts perl. Le fichier corrompu n'était pas /usr/bin/perl (je l'ai comparé avec celui extrait du .deb) mais un autre que je n'ai pas réussi à identifier, peut-être une bibliothèque. En fait à chaque fois c'est seulement l'image du fichier dans le cache disque en mémoire vive qui est corrompue, le fichier lui-même sur le disque est intact. Comme je ne sais pas comment purger un fichier du cache afin qu'il soit rechargé depuis le disque, je redémarre la machine et tout rentre dans l'ordre, jusqu'à la prochaine inversion de bit en mémoire. Pourtant j'ai testé la RAM plusieurs fois avec memtest86 qui ne signale aucune erreur. En fait je crains qu'il ne soit pas prévu pour détecter ce genre d'erreur, où un bit non modifié change d'état spontanément.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
François Boisson
Le Sat, 27 Jan 2007 15:44:16 +0100 Sylvain Sauvage a écrit:
Euh, bêtement, perl ne serait-il pas un lien vers perl5.8.4 ?
même inode (et le « 2 » indique que ce sont les 2 seuls noms). (5.8.8 en Sid)
Nom de Zeus, j'ai pensé à vérifier que perl n'était pas un lien vers perl5.8.4 mais pas l'inverse (je trouve ça illogique!). Bon désolé du bruit et merci de toutes les réponses :)
Pour Pascal, la machine est effectivement vieille, mais elle est sous surveillance permanente. Je constate régulièrement ce phénomène (en général le même bit passe à zéro sur tout une colonne d'octets lorsqu'on les range par ligne de 16. J'ai vu cela sur des machines récentes également (mais je les surveille moins, elles ne servent pas de serveurs en général).
Merci
François Boisson
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le Sat, 27 Jan 2007 15:44:16 +0100
Sylvain Sauvage <Sylvain.Sauvage@metanoesis.net> a écrit:
Euh, bêtement, perl ne serait-il pas un lien vers perl5.8.4 ?
même inode (et le « 2 » indique que ce sont les 2 seuls noms).
(5.8.8 en Sid)
Nom de Zeus, j'ai pensé à vérifier que perl n'était pas un lien vers
perl5.8.4 mais pas l'inverse (je trouve ça illogique!). Bon désolé du
bruit et merci de toutes les réponses :)
Pour Pascal, la machine est effectivement vieille, mais elle est sous
surveillance permanente. Je constate régulièrement ce phénomène (en
général le même bit passe à zéro sur tout une colonne d'octets
lorsqu'on les range par ligne de 16. J'ai vu cela sur des machines
récentes également (mais je les surveille moins, elles ne servent pas
de serveurs en général).
Merci
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
même inode (et le « 2 » indique que ce sont les 2 seuls noms). (5.8.8 en Sid)
Nom de Zeus, j'ai pensé à vérifier que perl n'était pas un lien vers perl5.8.4 mais pas l'inverse (je trouve ça illogique!). Bon désolé du bruit et merci de toutes les réponses :)
Pour Pascal, la machine est effectivement vieille, mais elle est sous surveillance permanente. Je constate régulièrement ce phénomène (en général le même bit passe à zéro sur tout une colonne d'octets lorsqu'on les range par ligne de 16. J'ai vu cela sur des machines récentes également (mais je les surveille moins, elles ne servent pas de serveurs en général).
Merci
François Boisson
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Pascal Hambourg
François Boisson a écrit :
Pour Pascal, la machine est effectivement vieille, mais elle est sous surveillance permanente. Je constate régulièrement ce phénomène (en général le même bit passe à zéro sur tout une colonne d'octets lorsqu'on les range par ligne de 16.
Comme il s'agit clairement d'une corruption de données en mémoire, c'était surtout pour dire qu'il n'était pas nécessaire de réinstaller les fichiers apparemment corrompus. Un reboot (si possible) ou un vidage du cache disque (si tu sais faire) aurait suffi.
J'ai vu cela sur des machines récentes également (mais je les surveille moins, elles ne servent pas de serveurs en général).
Les vieilles machines n'ont pas le monopole des erreurs mémoire, hélas.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
François Boisson a écrit :
Pour Pascal, la machine est effectivement vieille, mais elle est sous
surveillance permanente. Je constate régulièrement ce phénomène (en
général le même bit passe à zéro sur tout une colonne d'octets
lorsqu'on les range par ligne de 16.
Comme il s'agit clairement d'une corruption de données en mémoire,
c'était surtout pour dire qu'il n'était pas nécessaire de réinstaller
les fichiers apparemment corrompus. Un reboot (si possible) ou un vidage
du cache disque (si tu sais faire) aurait suffi.
J'ai vu cela sur des machines
récentes également (mais je les surveille moins, elles ne servent pas
de serveurs en général).
Les vieilles machines n'ont pas le monopole des erreurs mémoire, hélas.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Pour Pascal, la machine est effectivement vieille, mais elle est sous surveillance permanente. Je constate régulièrement ce phénomène (en général le même bit passe à zéro sur tout une colonne d'octets lorsqu'on les range par ligne de 16.
Comme il s'agit clairement d'une corruption de données en mémoire, c'était surtout pour dire qu'il n'était pas nécessaire de réinstaller les fichiers apparemment corrompus. Un reboot (si possible) ou un vidage du cache disque (si tu sais faire) aurait suffi.
J'ai vu cela sur des machines récentes également (mais je les surveille moins, elles ne servent pas de serveurs en général).
Les vieilles machines n'ont pas le monopole des erreurs mémoire, hélas.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
François Boisson
Le Sat, 27 Jan 2007 18:40:52 +0100 Pascal Hambourg a écrit:
Comme il s'agit clairement d'une corruption de données en mémoire, c'était surtout pour dire qu'il n'était pas nécessaire de réinstaller les fichiers apparemment corrompus. Un reboot (si possible) ou un vidage du cache disque (si tu sais faire) aurait suffi.
Pas sur, la machine est un serveur et perl ne sert quasiment jamais, Sinon le fichier a été déclaré corrompu après cette modification et effectivement le md5sum ne correspondait pas (je l'ai rappatrié chez moi). L'origine est peut être due à la mémoire mais le fichier était réellement corrompu. N'ayant plus la version pile du paquet, je l'ai ponctuellement réinstallé (petite MAJ).
Frrançois Boisson
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le Sat, 27 Jan 2007 18:40:52 +0100
Pascal Hambourg <pascal.mail@plouf.fr.eu.org> a écrit:
Comme il s'agit clairement d'une corruption de données en mémoire,
c'était surtout pour dire qu'il n'était pas nécessaire de réinstaller
les fichiers apparemment corrompus. Un reboot (si possible) ou un vidage
du cache disque (si tu sais faire) aurait suffi.
Pas sur, la machine est un serveur et perl ne sert quasiment jamais,
Sinon le fichier a été déclaré corrompu après cette modification et
effectivement le md5sum ne correspondait pas (je l'ai rappatrié chez
moi). L'origine est peut être due à la mémoire mais le fichier était
réellement corrompu. N'ayant plus la version pile du paquet, je l'ai
ponctuellement réinstallé (petite MAJ).
Frrançois Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le Sat, 27 Jan 2007 18:40:52 +0100 Pascal Hambourg a écrit:
Comme il s'agit clairement d'une corruption de données en mémoire, c'était surtout pour dire qu'il n'était pas nécessaire de réinstaller les fichiers apparemment corrompus. Un reboot (si possible) ou un vidage du cache disque (si tu sais faire) aurait suffi.
Pas sur, la machine est un serveur et perl ne sert quasiment jamais, Sinon le fichier a été déclaré corrompu après cette modification et effectivement le md5sum ne correspondait pas (je l'ai rappatrié chez moi). L'origine est peut être due à la mémoire mais le fichier était réellement corrompu. N'ayant plus la version pile du paquet, je l'ai ponctuellement réinstallé (petite MAJ).
Frrançois Boisson
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Pascal Hambourg
François Boisson a écrit :
Pascal Hambourg a écrit:
Comme il s'agit clairement d'une corruption de données en mémoire, c'était surtout pour dire qu'il n'était pas nécessaire de réinstaller les fichiers apparemment corrompus. Un reboot (si possible) ou un vidage du cache disque (si tu sais faire) aurait suffi.
Pas sur, la machine est un serveur et perl ne sert quasiment jamais,
En es-tu si sûr ? Sur ma Sarge cron exécute quotidiennement au moins un script perl appartenant à dpkg, ça peut suffire à ce que perl soit maintenu dans le cache disque en permanence.
D'autre part je peux me tromper mais compte tenu de la structure linéaire du stockage des données sur un disque dur et matricielle en RAM, et du contrôle d'erreur réalisé par un disque, le fait que toute une rangée de bits dans plusieurs mots consécutifs ait changé d'état me fait penser beaucoup plus à une erreur mémoire qu'à une erreur sur le disque.
Sinon le fichier a été déclaré corrompu après cette modification et effectivement le md5sum ne correspondait pas (je l'ai rappatrié chez moi). L'origine est peut être due à la mémoire mais le fichier était réellement corrompu.
En es-tu sûr ? Tant que des données du disque sont en cache, en les lisant ou en les copiant via le système de fichiers on n'accède qu'à leur copie dans le cache (c'est le but), pas aux données originales stockées sur le disque.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
François Boisson a écrit :
Pascal Hambourg <pascal.mail@plouf.fr.eu.org> a écrit:
Comme il s'agit clairement d'une corruption de données en mémoire,
c'était surtout pour dire qu'il n'était pas nécessaire de réinstaller
les fichiers apparemment corrompus. Un reboot (si possible) ou un vidage
du cache disque (si tu sais faire) aurait suffi.
Pas sur, la machine est un serveur et perl ne sert quasiment jamais,
En es-tu si sûr ? Sur ma Sarge cron exécute quotidiennement au moins un
script perl appartenant à dpkg, ça peut suffire à ce que perl soit
maintenu dans le cache disque en permanence.
D'autre part je peux me tromper mais compte tenu de la structure
linéaire du stockage des données sur un disque dur et matricielle en
RAM, et du contrôle d'erreur réalisé par un disque, le fait que toute
une rangée de bits dans plusieurs mots consécutifs ait changé d'état me
fait penser beaucoup plus à une erreur mémoire qu'à une erreur sur le
disque.
Sinon le fichier a été déclaré corrompu après cette modification et
effectivement le md5sum ne correspondait pas (je l'ai rappatrié chez
moi). L'origine est peut être due à la mémoire mais le fichier était
réellement corrompu.
En es-tu sûr ? Tant que des données du disque sont en cache, en les
lisant ou en les copiant via le système de fichiers on n'accède qu'à
leur copie dans le cache (c'est le but), pas aux données originales
stockées sur le disque.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Comme il s'agit clairement d'une corruption de données en mémoire, c'était surtout pour dire qu'il n'était pas nécessaire de réinstaller les fichiers apparemment corrompus. Un reboot (si possible) ou un vidage du cache disque (si tu sais faire) aurait suffi.
Pas sur, la machine est un serveur et perl ne sert quasiment jamais,
En es-tu si sûr ? Sur ma Sarge cron exécute quotidiennement au moins un script perl appartenant à dpkg, ça peut suffire à ce que perl soit maintenu dans le cache disque en permanence.
D'autre part je peux me tromper mais compte tenu de la structure linéaire du stockage des données sur un disque dur et matricielle en RAM, et du contrôle d'erreur réalisé par un disque, le fait que toute une rangée de bits dans plusieurs mots consécutifs ait changé d'état me fait penser beaucoup plus à une erreur mémoire qu'à une erreur sur le disque.
Sinon le fichier a été déclaré corrompu après cette modification et effectivement le md5sum ne correspondait pas (je l'ai rappatrié chez moi). L'origine est peut être due à la mémoire mais le fichier était réellement corrompu.
En es-tu sûr ? Tant que des données du disque sont en cache, en les lisant ou en les copiant via le système de fichiers on n'accède qu'à leur copie dans le cache (c'est le but), pas aux données originales stockées sur le disque.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
DoMinix
François Boisson a écrit :
Le Sat, 27 Jan 2007 18:40:52 +0100 Pascal Hambourg a écrit:
Comme il s'agit clairement d'une corruption de données en mémoire, c'était surtout pour dire qu'il n'était pas nécessaire de réinstaller les fichiers apparemment corrompus. Un reboot (si possible) ou un vidage du cache disque (si tu sais faire) aurait suffi.
Pas sur, la machine est un serveur et perl ne sert quasiment jamais, Sinon le fichier a été déclaré corrompu après cette modification et effectivement le md5sum ne correspondait pas (je l'ai rappatrié chez moi). L'origine est peut être due à la mémoire mais le fichier était réellement corrompu. N'ayant plus la version pile du paquet, je l'ai ponctuellement réinstallé (petite MAJ).
Frrançois Boisson
ça resemble a des secteurs se defectuants ... ce genre de phenomene m'amenerai verifier completement le disque. smartctl -t long /dev/lebondisque
mes 2 xpf.
-- dominix
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
François Boisson a écrit :
Le Sat, 27 Jan 2007 18:40:52 +0100
Pascal Hambourg <pascal.mail@plouf.fr.eu.org> a écrit:
Comme il s'agit clairement d'une corruption de données en mémoire,
c'était surtout pour dire qu'il n'était pas nécessaire de réinstaller
les fichiers apparemment corrompus. Un reboot (si possible) ou un vidage
du cache disque (si tu sais faire) aurait suffi.
Pas sur, la machine est un serveur et perl ne sert quasiment jamais,
Sinon le fichier a été déclaré corrompu après cette modification et
effectivement le md5sum ne correspondait pas (je l'ai rappatrié chez
moi). L'origine est peut être due à la mémoire mais le fichier était
réellement corrompu. N'ayant plus la version pile du paquet, je l'ai
ponctuellement réinstallé (petite MAJ).
Frrançois Boisson
ça resemble a des secteurs se defectuants ...
ce genre de phenomene m'amenerai verifier completement le disque.
smartctl -t long /dev/lebondisque
mes 2 xpf.
--
dominix
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le Sat, 27 Jan 2007 18:40:52 +0100 Pascal Hambourg a écrit:
Comme il s'agit clairement d'une corruption de données en mémoire, c'était surtout pour dire qu'il n'était pas nécessaire de réinstaller les fichiers apparemment corrompus. Un reboot (si possible) ou un vidage du cache disque (si tu sais faire) aurait suffi.
Pas sur, la machine est un serveur et perl ne sert quasiment jamais, Sinon le fichier a été déclaré corrompu après cette modification et effectivement le md5sum ne correspondait pas (je l'ai rappatrié chez moi). L'origine est peut être due à la mémoire mais le fichier était réellement corrompu. N'ayant plus la version pile du paquet, je l'ai ponctuellement réinstallé (petite MAJ).
Frrançois Boisson
ça resemble a des secteurs se defectuants ... ce genre de phenomene m'amenerai verifier completement le disque. smartctl -t long /dev/lebondisque
mes 2 xpf.
-- dominix
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Pascal Hambourg
DoMinix a écrit :
ça resemble a des secteurs se defectuants ...
Je ne suis pas du tout d'accord. François a écrit : "le même bit passe à zéro sur tout une colonne d'octets". Or sur un disque dur les bits des secteurs sont encodés et enregistrés en série, il n'y a aucune raison matérielle pour que plusieurs bits aussi régulièrement espacés passent en erreur simultanément. D'autre part, l'intégrité des données enregistrées sur un disque dur est protégée par un code correcteur d'erreur (appelé ECC ou CRC) dont la vérification en lecture n'aurait jamais laissé passer autant d'erreurs sans signaler le secteur comme défectueux. En revanche, dans une mémoire RAM le stockage des bits est organisé en matrices de lignes et de colonnes, qui est bien plus compatible avec le défaut observé. Un problème de rafraîchissement sur une ligne ou une colonne a pu causer le passage à zéro des bits. Et sans contrôle d'erreur ECC, qui est assez rare avec la RAM, l'erreur n'est pas détectable au niveau matériel.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
DoMinix a écrit :
ça resemble a des secteurs se defectuants ...
Je ne suis pas du tout d'accord. François a écrit : "le même bit passe à
zéro sur tout une colonne d'octets". Or sur un disque dur les bits des
secteurs sont encodés et enregistrés en série, il n'y a aucune raison
matérielle pour que plusieurs bits aussi régulièrement espacés passent
en erreur simultanément. D'autre part, l'intégrité des données
enregistrées sur un disque dur est protégée par un code correcteur
d'erreur (appelé ECC ou CRC) dont la vérification en lecture n'aurait
jamais laissé passer autant d'erreurs sans signaler le secteur comme
défectueux. En revanche, dans une mémoire RAM le stockage des bits est
organisé en matrices de lignes et de colonnes, qui est bien plus
compatible avec le défaut observé. Un problème de rafraîchissement sur
une ligne ou une colonne a pu causer le passage à zéro des bits. Et sans
contrôle d'erreur ECC, qui est assez rare avec la RAM, l'erreur n'est
pas détectable au niveau matériel.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Je ne suis pas du tout d'accord. François a écrit : "le même bit passe à zéro sur tout une colonne d'octets". Or sur un disque dur les bits des secteurs sont encodés et enregistrés en série, il n'y a aucune raison matérielle pour que plusieurs bits aussi régulièrement espacés passent en erreur simultanément. D'autre part, l'intégrité des données enregistrées sur un disque dur est protégée par un code correcteur d'erreur (appelé ECC ou CRC) dont la vérification en lecture n'aurait jamais laissé passer autant d'erreurs sans signaler le secteur comme défectueux. En revanche, dans une mémoire RAM le stockage des bits est organisé en matrices de lignes et de colonnes, qui est bien plus compatible avec le défaut observé. Un problème de rafraîchissement sur une ligne ou une colonne a pu causer le passage à zéro des bits. Et sans contrôle d'erreur ECC, qui est assez rare avec la RAM, l'erreur n'est pas détectable au niveau matériel.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
