Bug 459486 - Problem with udev daemon on RHEL 5.2
Summary: Problem with udev daemon on RHEL 5.2
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: freeIPA
Classification: Retired
Component: ipa-server
Version: 1.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: v2 release
Assignee: Rob Crittenden
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-08-19 11:16 UTC by Frederic Hornain
Modified: 2015-01-04 23:33 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-06-17 14:37:09 UTC
Embargoed:


Attachments (Terms of Use)

Description Frederic Hornain 2008-08-19 11:16:16 UTC
Description of problem:
First of all I have install IPA client and server on two different machine with the RHEL 5.2. without any patches.
In addition, I am using ipa-server-1.0.0-17.el5ipa.i386.rpm  and  ipa-client-1.0.0-17.el5ipa.i386.rpm version.

So after the installation of IPA, all is working perfectly. None the less as soon as I restart one of the machines. I have the following message :

udev[476]: nss_ldap: failed to bind to LDAP server ldap://blabla.com: Can't contact ldap server.
udev[476]: nss_ldap: reconnecting to LDAP server (sleeping X seconds)
etc...

And I can wait a long time if I do no CTRL+C

From that moment the process is really really slow.

So as soon as I can be connected on the client or the server I have to do as root a start_dev in order to fix that problem.

By the way if this problem occurs on the server, I have to restart dirsrv as well.

So I thought the change the start sequence however start_udev is started with /etc/rc.d/rc.sysinit.

So I do not really know how to fix that except to do that manipulation every time the machine is started.

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

ipa-server-1.0.0-17.el5ipa.i386.rpm 
ipa-client-1.0.0-17.el5ipa.i386.rpm

How reproducible:
Install on two machine the base of RHEL 5.2 without any update.
Install IPA as written in the IPA documentation.
Start the IPA Server deamon
Configure the client in order to contact the IPA server
Normally everything should working well.
Restart on of these machine.
And then Redo your connection with a user defined in IPA.

Steps to Reproduce:
1. Install on two machine the base of RHEL 5.2 without any update.
2. Install IPA as written in the IPA documentation.
3. Start the IPA Server deamon
4. Configure the client in order to contact the IPA server
5. Normally everything should working well.
6. Restart on of these machine.
7. And then Redo your connection with a user defined in IPA.
8. Then the problem occurs
  
Actual results:
udev[476]: nss_ldap: failed to bind to LDAP server ldap://blabla.com: Can't contact ldap server.
udev[476]: nss_ldap: reconnecting to LDAP server (sleeping X seconds)
etc...

Expected results:
You should be able to be connected on the client machine.
Or if it is the server, you should be able to use correctly the server without restarting dirsrv

Additional info:
By the way, Great job. Carry on!
Feel free to contact me.

Comment 1 Simo Sorce 2008-08-19 13:55:45 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 ?

Comment 2 Frederic Hornain 2008-08-21 09:24:27 UTC
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

Comment 3 Frederic Hornain 2008-08-21 09:42:08 UTC
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

Comment 4 Simo Sorce 2008-08-21 12:43:17 UTC
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.

Comment 5 Kay Sievers 2008-11-03 01:33:42 UTC
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.

Comment 6 Simo Sorce 2008-11-03 13:04:50 UTC
The "unknown" user/group may also be addedd to the nss_ldap blacklist too. See ldap.conf


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