Re: aptitude segfault --> hacké ?
Le Mercredi, 30 Novembre 2005 13.55, Frédéric Bothamy a écrit :
> * steve <dlist@bluewin.ch> [2005-11-30 13:17] :
> > Le Mercredi, 30 Novembre 2005 13.04, Frédéric Bothamy a écrit :
> > > * steve <dlist@bluewin.ch> [2005-11-30 12:22] :
> > > > Le Mercredi, 30 Novembre 2005 11.54, Frédéric Bothamy a écrit :
> > > > > * steve <dlist@bluewin.ch> [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 : sdl@jabber.org
Reply to: