Bug 473483 - nis acting very strangly....
nis acting very strangly....
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
10
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Andreas Schwab
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-28 14:30 EST by Stephen Adler
Modified: 2016-11-24 07:25 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 02:00:44 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 Stephen Adler 2008-11-28 14:30:16 EST
Description of problem:

Firefox will crash when calling gethostbyname.


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

Fedora 10


How reproducible:

Every Time


Steps to Reproduce:
1. You have to setup a network which has nis running on it.
2. You have to assign a hostname to your web server which you have so that the name will resolve both via nis and dns. (i.e. have it in your yp server /etc/hosts file and registered with whom ever you bought the hostname from)
3. Have a web server running on this host
4. Then surf to the host and watch firefox crash.

There is a work around. In nsswitch.conf, reverse the order of nis and dns for the host lookup as in

    hosts:      files dns nis

Then gethostbyname will look in dns first, find it there, and not ask for it from the nis server (aka ypserver). If it asks for it form the nis server, crashola!

  
Actual results:


Expected results:

Firefox should not crash


Additional info:

There is clearly something odd, and the firefox crashing is the worst of it. But in general, hostname lookups are very slow. About 20% of the time, firefox will come back with a "lookup failed, check your dns" error messages with a retry button right under it. Clicking on the retry button will then get me to the web page. Something is funky with nis....
Comment 1 Stephen Adler 2008-11-28 15:01:21 EST
Here's another example, ssh bombed on me. One thing to note, the yp server is running rhel5.

[root@basement00 ~]# rpm -qa | grep -i ypserv
ypserv-2.19-3


what follows is the output of my ssh command....

[adler@office01 ~]$ ssh ssh-box
*** glibc detected *** ssh: munmap_chunk(): invalid pointer: 0x00007fbee821ba8e ***
======= Backtrace: =========
/lib64/libc.so.6[0x1a86e98]
/lib64/libnss_nis.so.2(_nss_nis_gethostbyname4_r+0x1b6)[0x302c836]
/lib64/libc.so.6[0x1adc4d6]
/lib64/libc.so.6(getaddrinfo+0x1cd)[0x1ade19d]
ssh[0x7fbee7eae957]
ssh(main+0xefd)[0x7fbee7ea4d5d]
/lib64/libc.so.6(__libc_start_main+0xe6)[0x1a2d546]
ssh[0x7fbee7ea3819]
======= Memory map: ========
00110000-00130000 r-xp 00000000 09:00 12210554                           /lib64/ld-2.9.so
0032f000-00330000 r--p 0001f000 09:00 12210554                           /lib64/ld-2.9.so
00330000-00331000 rw-p 00020000 09:00 12210554                           /lib64/ld-2.9.so
00331000-00471000 r-xp 00000000 09:00 12210729                           /lib64/libcrypto.so.0.9.8g
00471000-00670000 ---p 00140000 09:00 12210729                           /lib64/libcrypto.so.0.9.8g
00670000-00691000 rw-p 0013f000 09:00 12210729                           /lib64/libcrypto.so.0.9.8g
00691000-00694000 rw-p 00691000 00:00 0 
00694000-00696000 r-xp 00000000 09:00 12210588                           /lib64/libutil-2.9.so
00696000-00895000 ---p 00002000 09:00 12210588                           /lib64/libutil-2.9.so
00895000-00896000 r--p 00001000 09:00 12210588                           /lib64/libutil-2.9.so
00896000-00897000 rw-p 00002000 09:00 12210588                           /lib64/libutil-2.9.so
00897000-008ac000 r-xp 00000000 09:00 12210574                           /lib64/libz.so.1.2.3
008ac000-00aab000 ---p 00015000 09:00 12210574                           /lib64/libz.so.1.2.3
00aab000-00aac000 rw-p 00014000 09:00 12210574                           /lib64/libz.so.1.2.3
00aac000-00ac2000 r-xp 00000000 09:00 12210558                           /lib64/libnsl-2.9.so
00ac2000-00cc2000 ---p 00016000 09:00 12210558                           /lib64/libnsl-2.9.so
00cc2000-00cc3000 r--p 00016000 09:00 12210558                           /lib64/libnsl-2.9.so
00cc3000-00cc4000 rw-p 00017000 09:00 12210558                           /lib64/libnsl-2.9.so
00cc4000-00cc6000 rw-p 00cc4000 00:00 0 
00cc6000-00ccf000 r-xp 00000000 09:00 12210725                           /lib64/libcrypt-2.9.so
00ccf000-00ece000 ---p 00009000 09:00 12210725                           /lib64/libcrypt-2.9.so
00ece000-00ecf000 r--p 00008000 09:00 12210725                           /lib64/libcrypt-2.9.so
00ecf000-00ed0000 rw-p 00009000 09:00 12210725                           /lib64/libcrypt-2.9.so
00ed0000-00efe000 rw-p 00ed0000 00:00 0 
00efe000-00f12000 r-xp 00000000 09:00 12210564                           /lib64/libresolv-2.9.so
00f12000-01112000 ---p 00014000 09:00 12210564                           /lib64/libresolv-2.9.so
01112000-01113000 r--p 00014000 09:00 12210564                           /lib64/libresolv-2.9.so
01113000-01114000 rw-p 00015000 09:00 12210564                           /lib64/libresolv-2.9.so
01114000-01116000 rw-p 01114000 00:00 0 
01116000-01144000 r-xp 00000000 09:00 2426757                            /usr/lib64/libgssapi_krb5.so.2.2
01144000-01343000 ---p 0002e000 09:00 2426757                            /usr/lib64/libgssapi_krb5.so.2.2
01343000-01345000 rw-p 0002d000 09:00 2426757                            /usr/lib64/libgssapi_krb5.so.2.2
01345000-013e3000 r-xp 00000000 09:00 2426756                            /usr/lib64/libkrb5.so.3.3
013e3000-015e3000 ---p 0009e000 09:00 2426756                            /usr/lib64/libkrb5.so.3.3
015e3000-015e7000 rw-p 0009e000 09:00 2426756                            /usr/lib64/libkrb5.so.3.3
015e7000-0160b000 r-xp 00000000 09:00 2426755                            /usr/lib64/libk5crypto.so.3.1
0160b000-0180a000 ---p 00024000 09:00 2426755                            /usr/lib64/libk5crypto.so.3.1
0180a000-0180c000 rw-p 00023000 09:00 2426755                            /usr/lib64/libk5crypto.so.3.1
0180c000-0180f000 r-xp 00000000 09:00 12210702                           /lib64/libcom_err.so.2.1
0180f000-01a0e000 ---p 00003000 09:00 12210702                           /lib64/libcom_err.so.2.1
01a0e000-01a0f000 rw-p 000020Aborted
[adler@office01 ~]$ ssh ssh-box
Comment 2 Stephen Adler 2008-11-30 06:11:02 EST
I've done some more investigation on this problem and have found out the following. If I have multiple aliases in my /etc/hosts file on the yp master, then the gethostbyname causes application to bomb. In otherwords the following entry causes the client application to bomb

/etc/hosts entry on yp(nis) master....
123.123.123.123   some.ip.name.com  ipname1 ipname2


the following command will bomb on the client (my workstation running fedora 10)

  ssh ipname1


if I change the some.ip.name.com entry in /etc/hosts on the yp master to this

123.123.123.123   some.ip.name.com  ipname1

then the command executed on the client (again, my workstation running fedora 10)

  ssh ipname1

works fine....

The nis server is running redhat 5.2.
Comment 3 Stephen Adler 2008-12-15 11:34:26 EST
I see that this bug has been assigned. The recent release of glibc 2.9-3 did not fix this. Also, my system is an x86_64.

Good luck!
Comment 4 Ulrich Drepper 2008-12-30 12:03:02 EST
2.9-3 should fix this.  I cannot reproduce any problem with this version and I've fixed for 2.9-3 bugs in the NIS host alias handling.  You should make sure you really test the right version and don't have any old code in use.

If the problem persists you'll have to install the debuginfo package and show a complete backtrace and show the setup you use.
Comment 5 Bug Zapper 2009-11-18 04:02:49 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 6 Bug Zapper 2009-12-18 02:00:44 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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