Bug 459486
Summary: | Problem with udev daemon on RHEL 5.2 | ||
---|---|---|---|
Product: | [Retired] freeIPA | Reporter: | Frederic Hornain <fhornain> |
Component: | ipa-server | Assignee: | Rob Crittenden <rcritten> |
Status: | CLOSED NOTABUG | QA Contact: | Chandrasekar Kannan <ckannan> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 1.0 | CC: | benl, dpal, kay.sievers, ssorce |
Target Milestone: | v2 release | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-06-17 14:37:09 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Frederic Hornain
2008-08-19 11:16:16 UTC
Can you please edit ldap.conf and change the url to be ldap://localhost or, alternatively, make sure the server name is in /etc/hosts ? This should solve the problem of nss_ldap trying to contact the ldap server before it is up and running by avoiding host resolution timeouts. Does this, help ? Hi Simo, Unfortunatly, no. I have checked the /etc/ldap.conf on the server and it contains correctly the ldap link to localhost - uri ldap://localhost - In addition, as recommended in the offical documentation I have correctly set the full and short server name in the /etc/hosts file on the server as well as the client. -192.x.x.x ipaserver.xxx.xxx ipaserver - So I still have the problem on the ipa client and the ipa server. Nonetheless, you gave me an idea and see if can use it to fix my problem. Thanks in advance for your great help. Anyway, your help is welcome in order to fix that problem Keep you in touch if I've got something new BR Fred Hi again Simo, OK, I found it. Indeed, the starting sequence of the udevd daemon is really slow by the fact that it do not find the ldap - even if it is set to localhost or 127.0.0.1 -. Then what I did - thinking the udev deamon was waiting after something it could not retreive - was a CTRL+C after the apparition of few error messages indicating that udev could not join the ldap server -see above in the bug report -. it was a mistake. I should not do a CTRL+C. I would have to wait patiently after the start of the udevd daemon even if I had error message. OK, I assume that is fixed for the server part. Well, I am going to check that behaviour on the client side as soon as I will have time - maybe tomorrow -. Thanks in advance for your great help. Keep you in touch if I've got something new By the way, IPA is great job if you can spread the word to the dev team. BR Fred Fred, udev is probably trying to lookup some user or group, and, not finding it in the "files" database it might be trying to search it in ldap. If you can determine which user or group that is, we can add it to the black list in /etc/ldap.conf, and that should help making it speed up, as nss_ldap would not waste time trying to contact the ldap server. Udev just uses glibc's getgrnam() which hangs in the ldap timeout. Some package probably added a udev rules file with an unknown system user/group, or your config does not try local files before contacting ldap. You need to make sure, that all OWNER= and GROUP= keys in udev rules have only values which are in your local /etc/group, /etc/passwd database, so glibc/nss will not try to contact ldap, if configured to read the local files first. The "unknown" user/group may also be addedd to the nss_ldap blacklist too. See ldap.conf |