Description of problem:
After adding the service "ldap" after "dns" in the "hosts:" line
of /etc/nsswitch.conf most program are able to resolve hostnames
only present in ldap. But ping (and traceroute) hangs somewhere within
( libnss_ldap with debugging stops after: "nss_ldap: ==> ldap_init" )
( strace stops at "futex(0x375a8c, FUTEX_WAIT, 2, NULL" )
This is the same for known and unknown hosts.
Steps to Reproduce:
1. add "ldap" at the end of "hosts:" in /etc/nsswitch.conf
2. ping xyz
Actual Results: ... never returns
Expected Results: should ping host or return error message
- installation with kickstart and latest fedora core 1 updates
- "getent hosts xyz" and "getent -s "dns ldap" hosts xyz" works but
"getent -s "ldap" hosts xyz" hangs (as expected).
Maybe "someone" changes the nsswitch services within ping?
I'm a bit confused now. When you add ldap to the end of your "hosts"
configuration in step 1, is "dns" (or anything which can be used to
resolve your directory server's name) listed before it?
If not, then nss_ldap can't determine how to contact the directory
server to resolve the directory server's host name to an IP address,
and the whole thing will break.
Marking notabug, per fedora-list thread at
Actually my nsswitch.conf looks like
hosts: files nis dns ldap
and all (files,nis,dns) can resolve all needed by LDAP!
All works fine with ldap BUT "ping" (and traceroute and maybe others)
PING is my problem
I see the same problem on RH9 after running up2date.
/etc/nsswitch.conf looks like:
hosts: files ldap dns
Name resolution doesn't work. When I do "getent hosts" I see the
entries from /etc/hosts and then get a segmentation fault
It is probably not the same Problem:
Try dns BEFORE ldap:
hosts: files dns ldap
(ldap needs the ip of the server and sometimes the hostname
of the client too, before it can resolve other addresses)
Maybe not the same problem, but either way it doesn't work. With
ldap before dns and specifying ip of directory server
in /etc/ldap.conf and /etc/openldap/ldap.conf name queries hang.
With dns before ldap, getent will return the entire hosts list, but
names not in dns won't resolve and getent won't match keys from the
Interestingly, this problem doesn't exist with NIS (I have to specify
the fqdn of my NIS master for a handful of machine that aren't on the
same subnet and can't broadcast for it).
A far as I remember LDAP performs a reverse lookup on the servers
ip (and maybe on the client too).
Just try dns before ldap and if that works put the needed
infos into /etc/hosts. You might need to put the host
in a line by itself with the "real ip" and the FQDN (not with 127.0.0.1)
This is what I have planned to try if my problem is solved .... someday.
There is another Problem with nss_ldap:
crond stops (process disappears) when a users crontab has changed :
Nov 25 15:48:41 luanda crond: (CRON) STARTUP (fork ok)
Nov 25 15:49:00 luanda CROND: (gasi) CMD (echo Hello >>x.x)
Nov 25 15:50:00 luanda CROND: (root) CMD (/usr/lib/sa/sa1 1 1)
Nov 25 15:50:00 luanda CROND: (gasi) CMD (echo Hello >>x.x)
Nov 25 15:51:00 luanda CROND: (gasi) CMD (echo Hello >>x.x)
Nov 25 15:51:17 luanda crontab: (gasi) BEGIN EDIT (gasi)
Nov 25 15:51:24 luanda crontab: (gasi) REPLACE (gasi)
Nov 25 15:51:24 luanda crontab: (gasi) END EDIT (gasi)
Nov 25 15:52:00 luanda crond: nss_ldap: reconnecting to LDAP
Nov 25 15:52:00 luanda crond: nss_ldap: reconnected to LDAP
The normal output would be (instead of nss_ldap):
Nov 25 16:14:00 luanda crond: (gasi) RELOAD (cron/gasi)
Adding on to the issue of name resolution, I downloaded the source
for nss_ldap from padl.com. After compiling and installing, name
resolution works fine (using hosts: files dns ldap in nsswitch.conf).
Your solution didn't work for me, unfortunately.
I have downloaded and installed nss_ldap from PADL, and I am still
getting the problem of ping blocking on a futex.
The system is FC1 SMP with all current updates applied.
I use nss_ldap-217-1 and it seems fixed most of the problems.
Using LD_ASSUME_KERNEL=2.4.1 the ping problem seems to be gone
(And using FC2 Test3 and a hint from Nigel Wade@Fedora-List)
Whatever this may be (a futex lock problem) ...
This seems to be related to nscd.
If nscd is running host resolution via ldap works, if nscd isn't
running it fails.
I didn't think nscd was a requirement for host resolution with ldap.
starting nscd seems to solve this problem!
nscd only helps if ldap is last (or after dns) in nsswitch.conf:
With "host: files ldap dns" ping will not return again and
nscd stops working!
That isn't the case here. With
hosts: files ldap dns
I get host resolution via LDAP. I did have to restart nscd after
changing the entry in /etc/nsswitch.conf to include ldap.
Ok: I finally got it (hopefully):
I missed that some libldap does a reverse lookup on the
ip number in ldap.conf (or the like).
So I need to add the ldap-server in /etc/hosts avoiding
the endless loop (and nscd so ping will not stop in futex).
I run into the same problem.
With "hosts: files ldap dns" I cant get ping ans gethostip working.
The client and the ldapserver are in /etc/hosts.
This one burned me as well. It hangs on the futex
Running with a local ldap server.
hosts: files ldap dns
So forward and reverse IPs resolve
I'm running FC1, but I upgraded to 217 just to make sure.
It would hang in the futex until I ran nscd, then it worked fine.
nscd shouldn't be required.
Fedora Core 1 is maintained by the Fedora Legacy project for security updates
only. If this problem is a security issue, please reopen and reassign to the
Fedora Legacy product. If it is not a security issue and hasn't been resolved in
the current FC5 updates or in the FC6 test release, reopen and change the
version to match.
NOTE: Fedora Core 1 is reaching the final end of support even by the Legacy
project. After Fedora Core 6 Test 2 is released (currently scheduled for July
26th), there will be no more security updates for FC1. Please use these next two
weeks to upgrade any remaining FC1 systems to a current release.
Closing per lack of response. Also note that FC1 and FC2 are no longer
supported even by Fedora Legacy. If this still occurs on FC3 or FC4, please
assign to that version and Fedora Legacy. If it still occurs on FC5 or FC6,
please reopen and assign to the correct version.
Sounds like upgrading nss_ldap fixed it, though.