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.