Red Hat Bugzilla – Bug 188281
getaddrinfo sensible to previous errno when nisplus enabled
Last modified: 2007-11-30 17:11:29 EST
+++ This bug was initially created as a clone of Bug #186592 +++
Description of problem:
It looks to me like the resolution here was to remove nisplus from the
nsswitch file. I think there's a more fundamental underlying problem.
Even if the nsswitch file does contain something like
file nisplus dns
the lookups ought to work, right?
Is nisplus somehow reporting that there is no answer, as opposed
to reporting that it does not know the answer?
[I leave the original text below]
getaddrinfo fails with latest errno status if nisplus is present in hosts
section of nsswitch.conf
Version-Release number of selected component (if applicable):
Steps to Reproduce:
have e.g. the following line in nsswitch.conf:
hosts: files nisplus dns
try the following code snippet:
errno = EBADF;
rc = getaddrinfo("www.google.com", NULL, NULL, &res);
rc is EAI_SYSTEM, with latest errno as it was.
rc should be zero
affects for instance wget:
tate ~ $ wget http://www.google.com/
Resolving www.google.com... failed: No such file or directory.
I know that nisplus isn't supported (cf bug 159279) ; however I've had this
cruft in nsswitch.conf files for a long time, and even though useless, having
nisplus mentioned hasn't been disruptive so far -- why should it break things now ?
-- Additional comment from firstname.lastname@example.org on 2006-03-24 16:36 EST --
The right thing to do is certainly to remove nisplus from nsswitch.conf
unless you are using NIS+ though.
-- Additional comment from email@example.com on 2006-03-24 16:37 EST --
*** Bug 186626 has been marked as a duplicate of this bug. ***
-- Additional comment from firstname.lastname@example.org on 2006-03-28 14:27 EST --
*** Bug 186661 has been marked as a duplicate of this bug. ***
-- Additional comment from email@example.com on 2006-03-29 10:27 EST --
Sorry. I accidently added this comment to a duplicate. I am re-entering it here:
I had the same problem on FC4 after the recent update to glibc-2.3.6-3
-- Additional comment from firstname.lastname@example.org on 2006-03-29 11:44 EST --
Should be fixed in rawhide glibc-2.4-5 (can be used in FC5 without fears too).
Please test it, whenever is FC5 glibc updated, it will be fixed there too.
-- Additional comment from email@example.com on 2006-03-30 07:36 EST --
Same happen to me after update in FC4 to latest version and after cross-grade
from RHL7.3 to FC5.
BTW: can one tell me why
1) after update, the new nsswitch.conf file was created as nsswitch.conf.rpmnew,
but there were no changes made before to the old one
# rpm -qf /etc/nsswitch.conf
# rpm -V glibc
shows nothing after upgrade, but still old nsswitch.conf (I would expect that
/etc/nsswitch.conf would appear, also /etc/localtime, but that's another issue)
-- Additional comment from firstname.lastname@example.org on 2006-03-30 07:51 EST --
Regarding to the rpm -V glibc do not show any changed files, can it be that
/etc/nsswitch.conf is specified in glibc.spec with %verify(not md5 size mtime)?
Makes this sense?
-- Additional comment from email@example.com on 2006-03-30 08:22 EST --
*** Bug 187320 has been marked as a duplicate of this bug. ***
-- Additional comment from firstname.lastname@example.org on 2006-04-03 07:17 EST --
*** Bug 187676 has been marked as a duplicate of this bug. ***
-- Additional comment from email@example.com on 2006-04-07 05:30 EST --
*** Bug 188212 has been marked as a duplicate of this bug. ***
Can you read the #186592 bugreport? All the info is there.
Yes, there is a bug in FC5 (and FC4 updates) glibc, it has been fixed in
rawhide glibc and eventually when a few other glibc fixes are done, it will
be released as FC5 update (and for FC4 similarly).
In the mean time, you can test rawhide glibc, or, as a workaround, you can
remove nisplus from your /etc/nsswitch.conf unless you are actually using it.
That's a good idea anyway, as it only slows things down when NIS+ is not
configured, but present in nsswitch.conf.
*** This bug has been marked as a duplicate of 186592 ***