Bugzilla – Bug 374990
getservbyport() broken in 10.3 (glibc regression?)
Last modified: 2008-12-04 18:31:33 UTC
While attempting to compile Python 2.4 (for Zope, etc.) some socket tests failed, specifically the test comparing the results of getservbyname() and getservbyport(). Digging deeper, I discovered it's not a Python problem at all, but a bug in glibc that is simply reflected in Python. I have attached a simple C program illustrating the bug. On systems with a working getservbyport() syscall, it should print the following: andrew@virt-apache-02:~$ ./a.out found service daytime for port 13/(null) found service daytime for port 13/tcp found service daytime for port 13/udp On 10.3, the call fails: andrew@test-app-01:~> ./a.out not found in services: port 13/(null) not found in services: port 13/tcp not found in services: port 13/udp With an 11.0 alpha 3 live CD, it's broken in a different way: andrew@linux:~> ./a.out found service spr-itunes for port 0 found service spr-itunes for port 0/tcp not found in services: port 13/udp You can also test for the problem with two lines in an interactive session of python: >>> import socket >>> socket.getservbyport(13) This will print either 'daytime' (success) or an exception (socket.error: port/proto not found). OpenSUSE 10.3 (and 11.0 alpha3) are the only OSes I've found this to be broken on. It works correctly in 10.2, as well as on SLSE 10sp1, Ubuntu 7.10 (glibc 2.6.1), RHEL4 (glibc 2.3.4), and even on other platforms such as FreeBSD and OpenSolaris.
Created attachment 204747 [details] example C test code Seems attachment got lost in initial report, adding again.
This works in 11.0 final; the bug is not critical enough for 10.3 backport.
This bug is NOT fixed in 11.0 final, with all updates applied (at least, not out of the box, but I have discovered a workaround). It fails in the same way as 11.0a3 (which is different from the 10.3 failure), where it looks up port 0 instead of the specified port. Here is a transcript (a.out is a fresh recompile of the C code attached to this bug report): ==== andrew@test-app-01:~> uname -a Linux test-app-01.vpr.int 2.6.25.9-0.2-pae #1 SMP 2008-06-28 00:00:07 +0200 i686 i686 i386 GNU/Linux andrew@test-app-01:~> cat /etc/SuSE-release openSUSE 11.0 (i586) VERSION = 11.0 andrew@test-app-01:~> rpm -q kernel-pae glibc kernel-pae-2.6.25.9-0.2 glibc-2.8-14.1 andrew@test-app-01:~> ./a.out found service spr-itunes for port 0/(null) found service spr-itunes for port 0/tcp not found in services: port 13/udp andrew@test-app-01:~> grep 'services:' /etc/nsswitch.conf services: files andrew@test-app-01:~> grep ' 13/' /etc/services daytime 13/tcp # Daytime (RFC 867) daytime 13/udp # Daytime (RFC 867) andrew@test-app-01:~> grep ' 0/' /etc/services # 0/tcp Reserved # 0/udp Reserved spr-itunes 0/tcp # Shirt Pocket netTunes spl-itunes 0/tcp # Shirt Pocket launchTunes ==== I did however, have an epiphany and discover that the breakage is apparently due to nscd: ==== andrew@test-app-01:~> sudo /etc/init.d/nscd stop Shutting down Name Service Cache Daemon done andrew@test-app-01:~> ./a.out found service daytime for port 13/(null) found service daytime for port 13/tcp found service daytime for port 13/udp andrew@test-app-01:~> sudo /etc/init.d/nscd start Starting Name Service Cache Daemon done andrew@test-app-01:~> ./a.out found service spr-itunes for port 0/(null) found service spr-itunes for port 0/tcp not found in services: port 13/udp ==== nscd is enabled in the default installation. I have not modified its configuration; this is on a fresh installation and reformat of 11.0. As you can see, it is only when nscd is running (and caching services) that the failure occurs. If I disable services caching in nscd.conf, the problem no longer occurs. Perhaps this bug should be reassigned to nscd. Stopping nscd also solves the problem in 10.3.
Reopening... see comment #3. Should I file a separate bug against nscd or repurpose this one?
We will fix this for 11.0 by virtue of updating nscd to the glibc-2.9 version where this works fine again. *** This bug has been marked as a duplicate of bug 387202 ***