Re: glibc, bug 438179 et avenir de/dans etch
Bonjour,
Le 26.09.2007 19:16, Pierre Habouzit a écrit :
> Je ne sais pas quelles sont les conditions d'utilisation du programme,
> donc il est difficile de valider quoi que ce soit. Il y a mille raisons
> pour lesquelles ça a l'air d'être trié (nscd notamment). Mais:
>
> (1) la rule 9 est à propos des plus longs préfixes, or vu que la
> différence entre 165 et 166 est uniquement sur les deux derniers
> bits, le test est tout simplement idiot.
Mon test est probablement idiot, mais il met en évidence un comportement que
j'ai sur plusieurs dizaines de serveurs et que j'essaye tant bien que mal de
comprendre depuis plusieurs jours. Avant de venir passer pour un âne sur une
liste debian-devel archivée sur internet (ce qui n'était pas franchement mon
rêve je dois bien te l'avouer ;-) ), j'ai parlé du problème à un ami qui a pu le
reproduire sur ses propres serveurs en Debian etch.
Le rapprochement entre mon problème et le bug 438179 est peut-être malheureux.
Néanmoins, j'ai un problème, qui touche la glibc de Etch, qui n'est apparemment
pas si isolé que cela puisque nous sommes au minimum deux à l'avoir.
Peut-être est-il lié à l'environnement (matériel, logiciel, ou réseau) mais je
dois bien avouer que je suis à cours de piste. Par ailleurs, en patchant la
glibc 2.3.6 au niveau de la règle 9 (voir plus bas), je n'ai plus le problème.
Si je refais le test sur la glibc de Etch avec le petit programme du mail
précédent et en arrêtant le plus de démons possibles (voir fichier ps-ed.txt
joint) :
$ cat /etc/debian_version
4.0
$ dpkg -l "libc6*" |grep ^i
ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries
Avec getaddrinfo :
$ ./reso-dns ldaprs.mon.domaine getaddrinfo
getaddrinfo : ldaprs.mon.domaine 10.xxx.yyy.165 10.xxx.yyy.166
$ ./reso-dns ldaprs.mon.domaine getaddrinfo
getaddrinfo : ldaprs.mon.domaine 10.xxx.yyy.165 10.xxx.yyy.166
$ ./reso-dns ldaprs.mon.domaine getaddrinfo
getaddrinfo : ldaprs.mon.domaine 10.xxx.yyy.165 10.xxx.yyy.166
$ ./reso-dns ldaprs.mon.domaine getaddrinfo
getaddrinfo : ldaprs.mon.domaine 10.xxx.yyy.165 10.xxx.yyy.166
Avec gethostbyname :
$ ./reso-dns ldaprs.mon.domaine gethostbyname
gethostbyname : ldaprs.mon.domaine 10.xxx.yyy.165 10.xxx.yyy.166
$ ./reso-dns ldaprs.mon.domaine gethostbyname
gethostbyname : ldaprs.mon.domaine 10.xxx.yyy.166 10.xxx.yyy.165
$ ./reso-dns ldaprs.mon.domaine gethostbyname
gethostbyname : ldaprs.mon.domaine 10.xxx.yyy.165 10.xxx.yyy.166
$ ./reso-dns ldaprs.mon.domaine gethostbyname
gethostbyname : ldaprs.mon.domaine 10.xxx.yyy.166 10.xxx.yyy.165
Non seulement, il y a un tri, mais en plus sur des adresses proches...
De plus si j'applique ce patch à la glibc 2.3.6 [1], je n'ai plus le problème :
--- glibc-backup/sysdeps/posix/getaddrinfo.c 2005-10-16 12:15:30.000000000 +0200
+++ glibc-2.3.6/sysdeps/posix/getaddrinfo.c 2007-09-25 11:29:46.000000000 +0200
@@ -1392,7 +1392,7 @@
int bit1 = 0;
int bit2 = 0;
- if (a1->dest_addr->ai_family == PF_INET)
+ if (a1->dest_addr->ai_family == PF_INET && 0)
{
assert (a1->source_addr.ss_family == PF_INET);
assert (a2->source_addr.ss_family == PF_INET);
Or ce patch s'applique pile ici dans la fonction getaddrinfo de la glibc 2.3.6 :
/* Rule 9: Use longest matching prefix. */
if (a1->got_source_addr
&& a1->dest_addr->ai_family == a2->dest_addr->ai_family)
{
int bit1 = 0;
int bit2 = 0;
if (a1->dest_addr->ai_family == PF_INET)
{
assert (a1->source_addr.ss_family == PF_INET);
assert (a2->source_addr.ss_family == PF_INET);
[1] méthode utilisée pour appliquer le patch :
- dans l'archive debian de la glibc-2.3.6, création d'un fichier
"debian/patches/any/patch-sortv4.diff" avec ce patch.
- ajout de "any/patch-sortv4.diff -p 1" à la suite des "any/" dans le fichier
"debian/patches/series"
Voici les tests des getaddrinfo avec la glibc patchée :
$ ./reso-dns ldaprs.mon.domaine getaddrinfo
getaddrinfo : ldaprs.mon.domaine 10.xxx.yyy.165 10.xxx.yyy.166
$ ./reso-dns ldaprs.mon.domaine getaddrinfo
getaddrinfo : ldaprs.mon.domaine 10.xxx.yyy.166 10.xxx.yyy.165
$ ./reso-dns ldaprs.mon.domaine getaddrinfo
getaddrinfo : ldaprs.mon.domaine 10.xxx.yyy.165 10.xxx.yyy.166
$ ./reso-dns ldaprs.mon.domaine getaddrinfo
getaddrinfo : ldaprs.mon.domaine 10.xxx.yyy.166 10.xxx.yyy.165
Je suis prêt à faire d'autre test si cela peut aider.
Cordialement,
Julien$ ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 Sep04 ? 00:00:01 init [2]
root 2 1 0 Sep04 ? 00:00:00 [migration/0]
root 3 1 0 Sep04 ? 00:00:00 [ksoftirqd/0]
root 4 1 0 Sep04 ? 00:00:00 [migration/1]
root 5 1 0 Sep04 ? 00:00:00 [ksoftirqd/1]
root 6 1 0 Sep04 ? 00:00:00 [events/0]
root 7 1 0 Sep04 ? 00:00:00 [events/1]
root 8 1 0 Sep04 ? 00:00:00 [khelper]
root 9 1 0 Sep04 ? 00:00:00 [kthread]
root 13 9 0 Sep04 ? 00:00:00 [kblockd/0]
root 14 9 0 Sep04 ? 00:00:00 [kblockd/1]
root 15 9 0 Sep04 ? 00:00:00 [kacpid]
root 126 9 0 Sep04 ? 00:00:00 [kseriod]
root 168 9 0 Sep04 ? 00:00:00 [pdflush]
root 169 9 0 Sep04 ? 00:00:00 [pdflush]
root 170 9 0 Sep04 ? 00:00:00 [kswapd0]
root 171 9 0 Sep04 ? 00:00:00 [aio/0]
root 172 9 0 Sep04 ? 00:00:00 [aio/1]
root 328 1 0 Sep04 ? 00:00:00 [kirqd]
root 663 9 0 Sep04 ? 00:00:00 [khubd]
root 794 9 0 Sep04 ? 00:00:00 [scsi_eh_0]
root 810 9 0 Sep04 ? 00:00:00 [scsi_eh_1]
root 910 9 0 Sep04 ? 00:00:00 [scsi_eh_2]
root 1163 9 0 Sep04 ? 00:00:00 [kjournald]
root 1333 1 0 Sep04 ? 00:00:00 udevd --daemon
root 1690 9 0 Sep04 ? 00:00:00 [kpsmoused]
root 1699 9 0 Sep04 ? 00:00:00 [kedac]
root 1918 9 0 Sep04 ? 00:00:00 [kmirrord]
root 1951 9 0 Sep04 ? 00:00:00 [kjournald]
root 1953 9 0 Sep04 ? 00:00:00 [kjournald]
root 1955 9 0 Sep04 ? 00:00:00 [kjournald]
root 1957 9 0 Sep04 ? 00:00:01 [kjournald]
root 2171 1 0 Sep04 ? 00:00:00 /sbin/syslogd
root 2177 1 0 Sep04 ? 00:00:00 /sbin/klogd -x
root 2323 1 0 Sep04 ? 00:00:00 /usr/sbin/sshd
root 2446 1 0 Sep04 tty1 00:00:00 /sbin/getty 38400 tty1
root 2451 1 0 Sep04 tty2 00:00:00 /sbin/getty 38400 tty2
root 2452 1 0 Sep04 tty3 00:00:00 /sbin/getty 38400 tty3
root 2453 1 0 Sep04 tty4 00:00:00 /sbin/getty 38400 tty4
root 2454 1 0 Sep04 tty5 00:00:00 /sbin/getty 38400 tty5
root 2455 1 0 Sep04 tty6 00:00:00 /sbin/getty 38400 tty6
root 29455 2323 0 08:38 ? 00:00:00 sshd: admin [priv]
admin 29457 29455 0 08:38 ? 00:00:00 sshd: admin@pts/0
admin 29458 29457 0 08:38 pts/0 00:00:00 -bash
admin 30234 29458 0 11:48 pts/0 00:00:00 ps -ef
Reply to: