Le Mercredi, 30 Novembre 2005 13.55, Frédéric Bothamy a écrit : > * steve <[EMAIL PROTECTED]> [2005-11-30 13:17] : > > Le Mercredi, 30 Novembre 2005 13.04, Frédéric Bothamy a écrit : > > > * steve <[EMAIL PROTECTED]> [2005-11-30 12:22] : > > > > Le Mercredi, 30 Novembre 2005 11.54, Frédéric Bothamy a écrit : > > > > > * steve <[EMAIL PROTECTED]> [2005-11-30 11:41] : > > > > > > > > > > [...] > > > > > > > > > > > gettimeofday({1133346797, 410830}, NULL) = 0 > > > > > > gettimeofday({1133346797, 410870}, NULL) = 0 > > > > > > gettimeofday({1133346797, 410910}, NULL) = 0 > > > > > > --- SIGSEGV (Segmentation fault) @ 0 (0) --- > > > > > > +++ killed by SIGSEGV +++ > > > > > > > > > > > > > > > > > > Si ça vous dit quelque chose.... > > > > > > > > > > Soit tu as une bibliothèque (ou un exécutable) de corrompue (c'est > > > > > rare, mais cela peut arriver qu'un bit change de valeur sur un > > > > > disque dur entraînant des effets indésirables). Tu peux le vérifier > > > > > avec debsums par exemple. > > > > ben, par exemple : > > > > debsums: checksum mismatch cron file /etc/crontab > > debsums: checksum mismatch cupsys file /etc/cups/cupsd.conf > > debsums: checksum mismatch cxref file /etc/cxref/config > > debsums: checksum mismatch dhcp3-client file /etc/dhcp3/dhclient.conf > > debsums: checksum mismatch dhcp3-client file /etc/dhcp3/dhclient-script > > debsums: checksum mismatch initscripts file /etc/default/bootlogd > > debsums: checksum mismatch libldap2 file /etc/ldap/ldap.conf > > > > etc... Y'en a pas mal dans /etc. En fait la majorité. > > > > J'ai aussi > > > > debsums: checksum mismatch usbutils file /var/lib/usbutils/usb.ids > > > > mais ça me paraît normal, car j'ai dû faire un update-pciusb. > > Tu as lancé un "debsums -a" ? D'après la page de manuelle de la version > de testing (v2.0.19), les fichiers de configuration sont ignorés si on > ne le demande pas.
debsums -as. Je suis sous Sarge. > > > Le nombre de paquets n'ayant pas de somme MD5 pour ses fichiers > > > est limité (de mémoire, environ 20 ou 30). > > > > En effet: > > > > debsums -l | wc -l > > 31 > > Ceci pour les paquets que tu as installés, il y en a un peu plus pour > tous les paquets de l'archive. oui. > > > Pour tous les autres, cela te > > > permet de vérifier que le fichier présent sur le disque et la somme MD5 > > > indiquée par le paquet sont identiques. Quand à la possibilité que les > > > 2 soient modifiés en même temps, c'est très, très improbable > > > > mais pas impossible, et comme je suis un peu parano, je me méfie de cette > > méthode. D'ailleurs, man debsums dit : > > > > debsums est d'une utilité limitée en tant qu'outil de sécurité, à > > moins que le programme et tous les outils apparentés (dpkg, perl, > > Digest::MD5, etc.) soient lancés d'un média reconnu comme sûr > > (comme un cédérom de secours bootable, voir l'option --root) et que les > > sommes de contrôle aient étés calculées à partir des fichiers > > .deb (--generate=all) présents sur ce média ou certifiées en utilisant > > l'option --md5sums. > > Si tu es parano, tu fais une 2e install à l'identique de celle que tu as > et tu compares les fichiers entiers des 2 machines, pas seulement les > sommes MD5 (après tout, il y a forcément des collisions dans le calcul > des sommes MD5). Franchement, je ne crois pas qu'il soit bien nécessaire > de continuer sur cette voie avant d'être certain que ton matériel n'est > pas en cause. parano mais pas toujours consciencieux, malheureusement. Tu as raison, je vais d'abord memtester, et on verra le résultat. > > > (ou alors tu > > > as une corruption généralisée de tes données). > > > > non, ça il ne me semble pas. En fait seul 'aptitude' merdouille. > > Tu n'avais pas d'autres programmes qui plantaient à un moment donné ? ben ce matin, man ne fonctionnait pas, ssh non plus, su pareil, ainsi que less, d'où une certaine inquiétude.. > Est-ce qu'une compilation lourde (genre glibc, openoffice.org, noyau ou > autre) passe sans problème ? je n'ai pas essayé. J'ai compilé un noyau la semaine dernière, suite à ce même genre de problème, ce qui l'a d'ailleurs fait disparaître jusqu'à aujourd'hui, sans rencontrer de problème. > > > > > > Soit tu as un problème matériel (probablement la mémoire, mais cela > > > > > peut également être le processeur ou un autre composant qui > > > > > surchauffe). > > > > > > > > aïe ne me dis pas ça. Pas maintenant ! > > > > > > > > > Utilise memtest86 pour le vérifier. > > > > > > > > D'après ce que j'ai compris, on ne peut pas faire cela lorsque la > > > > machine tourne normalement, il faut booter sur une knoppix par > > > > exemple. Donc plus de réseau, etc... . Je vais faire ça cette nuit > > > > donc. > > > > > > Oui, il est uniquement possible de le faire après un redémarrage de la > > > machine. > > > > donc ce soir, j'ai des gens qui bossent maintenant. > > > > J'ai aussi découvert le paquet cpuburn. Mais cela me fait peur de > > l'utiliser vu les warnings que l'on peut lire dans le README. Un retour > > sur son utilisation serait la bienvenue. Dangereux ou pas ? > > D'après la description du paquet, oui. Le programme n'est intéressant > que si tu veux vérifier qu'un système de test tient la charge. c'est-à-dire ? -- steve jabber : [EMAIL PROTECTED]