Bug 186592 - getaddrinfo sensible to previous errno when nisplus enabled
getaddrinfo sensible to previous errno when nisplus enabled
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
5
All Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
: 176469 186626 186661 187320 187331 187676 188103 188212 188281 188562 190141 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-24 11:22 EST by Emmanuel Thomé
Modified: 2007-11-30 17:11 EST (History)
13 users (show)

See Also:
Fixed In Version: 2.4-5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-29 11:44:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Emmanuel Thomé 2006-03-24 11:22:54 EST
Description of problem:

getaddrinfo fails with latest errno status if nisplus is present in hosts
section of nsswitch.conf

Version-Release number of selected component (if applicable):

glibc-2.4-4

How reproducible:

always

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);

Actual results:

rc is EAI_SYSTEM, with latest errno as it was.

Expected results:

rc should be zero

Additional info:

affects for instance wget:

tate ~ $ wget http://www.google.com/
--17:19:50--  http://www.google.com/
           => `index.html'
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 ?
Comment 1 Jakub Jelinek 2006-03-24 16:36:37 EST
http://sources.redhat.com/ml/libc-hacker/2006-03/msg00038.html

The right thing to do is certainly to remove nisplus from nsswitch.conf
unless you are using NIS+ though.
Comment 2 Jakub Jelinek 2006-03-24 16:37:26 EST
*** Bug 186626 has been marked as a duplicate of this bug. ***
Comment 3 Jeremy Katz 2006-03-28 14:27:38 EST
*** Bug 186661 has been marked as a duplicate of this bug. ***
Comment 4 Chris Walter 2006-03-29 10:27:43 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

Comment 5 Jakub Jelinek 2006-03-29 11:44:05 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.
Comment 6 Peter Bieringer 2006-03-30 07:36:05 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

2) why
# rpm -qf /etc/nsswitch.conf
glibc-2.3.6-3

but 
# 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)
Comment 7 Peter Bieringer 2006-03-30 07:51:43 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?

Comment 8 Jakub Jelinek 2006-03-30 08:22:29 EST
*** Bug 187320 has been marked as a duplicate of this bug. ***
Comment 9 Jakub Jelinek 2006-04-03 07:17:32 EDT
*** Bug 187676 has been marked as a duplicate of this bug. ***
Comment 10 Jakub Jelinek 2006-04-07 05:30:26 EDT
*** Bug 188212 has been marked as a duplicate of this bug. ***
Comment 11 Jakub Jelinek 2006-04-07 12:33:02 EDT
*** Bug 188281 has been marked as a duplicate of this bug. ***
Comment 12 Jakub Jelinek 2006-04-10 16:18:09 EDT
*** Bug 188103 has been marked as a duplicate of this bug. ***
Comment 13 Jakub Jelinek 2006-04-11 05:23:45 EDT
*** Bug 188562 has been marked as a duplicate of this bug. ***
Comment 14 Jakub Jelinek 2006-04-13 05:02:12 EDT
*** Bug 188761 has been marked as a duplicate of this bug. ***
Comment 15 Jakub Jelinek 2006-04-14 02:42:02 EDT
*** Bug 188761 has been marked as a duplicate of this bug. ***
Comment 16 Jeremy Katz 2006-04-19 16:45:22 EDT
*** Bug 187331 has been marked as a duplicate of this bug. ***
Comment 17 Jakub Jelinek 2006-05-03 08:32:47 EDT
*** Bug 190141 has been marked as a duplicate of this bug. ***
Comment 18 Jakub Jelinek 2006-05-16 04:52:35 EDT
*** Bug 176469 has been marked as a duplicate of this bug. ***
Comment 19 Erik A. Espinoza 2006-07-18 13:35:50 EDT
Greetings,

There was a similar bug in FC4 on glibc-2.3.6-3, released March 27. On May 9th a
new glibc (2.3.6-4) was released in updates-testing for FC4. In the months since
glibc-2.3.6-4 has been put in updates-testing, there has been a ton of other
updates that have made it into the released updates. As such, I have two questions:

1) When will glibc-2.3.6-4 be put in the official release updates?
2) Was there any particular reason why this update hasn't made it into the
official release?

Thanks.
Comment 20 David Eisenstein 2006-09-07 06:46:13 EDT
Erik,

For Fedora Core 4, this is being now worked on by Fedora Legacy in Bug 200963. 
Hopefully, we in Legacy will have something officially released soon, thanks
to Jakub Jelinek's contribution.  If you wish to participate in the QA for
Bug 200963, we would welcome your participation.  Thanks!

Note You need to log in before you can comment on or make changes to this bug.