At some moment between 2.3.40 and 2.3.45 something changed in the
IP logic apparently. My system is Glibc2 based, it is non-networked
most of the time, so I do not run network-related daemons like
portmapper. When I first booted 2.3.45, I noticed that all operations
that require resolver slowed to a crawl. I did investigation and
found that glibc resolver, among other things, is trying to query
the portmapper at localhost. On 2.3.40, it immediately gets
ECONNREFUSED but on 2.3.45 it succeeds and waits for answer for
5 seconds, and then makes several more attempts. This is how it looks:
=========2.3.40:
bind(3, {sin_family=AF_INET, sin_port=htons(772), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
ioctl(3, FIONBIO, [1]) = 0
sendto(3, "Z\224\37\311\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0"..., 56, 0, {sin_family=AF_INET, sin_port=htons(111), sin_addr=inet_addr("127.0.0.1")}, 16) = 56
poll([{fd=3, events=POLLIN, revents=POLLERR}], 1, 5000) = 1
recvfrom(3, 0x805d938, 400, 0, 0xbffff5bc, 0xbffff568) = -1 ECONNREFUSED (Connection refused)
close(3)
==========2.3.45:
bind(3, {sin_family=AF_INET, sin_port=htons(767), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
ioctl(3, FIONBIO, [1]) = 0
sendto(3, "x\266\301\6\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3"..., 56, 0, {sin_family=AF_INET, sin_port=htons(111), sin_addr=inet_addr("127.0.0.1")}, 16) = 56
poll([{fd=3, events=POLLIN}], 1, 5000) = 0
ioctl(3, SIOCGIFCONF, 0xbfffd274) = 0
ioctl(3, SIOCGIFFLAGS, 0xbfffd27c) = 0
sendto(3, "x\266\301\6\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3"..., 56, 0, {sin_family=AF_INET, sin_port=htons(111), sin_addr=inet_addr("127.0.0.1")}, 16) = 56
poll([{fd=3, events=POLLIN}], 1, 5000) = 0
ioctl(3, SIOCGIFCONF, 0xbfffd274) = 0
ioctl(3, SIOCGIFFLAGS, 0xbfffd27c) = 0
sendto(3, "x\266\301\6\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3"..., 56, 0, {sin_family=AF_INET, sin_port=htons(111), sin_addr=inet_addr("127.0.0.1")}, 16) = 56
poll( <unfinished ...>
My questions are: is this change of semantics intended, what's the
reason behind it and what is the "proper" workaround?
Thanks.
Eugene
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:25 EST