Hi!
I've got a CentOS4.7-machine as a fileserver. The machine also serves as the LDAP-server against which all regular users are authenticated. The problem I am having is that the machine takes a very long time to boot. Most of the services start up rather quick, but three services take quite a long time (extending the boot time to over half an hour, which is .... long)
The three services are (in that order):
- NFS statd - LDAP - NFS quota
As soon as the LDAP-Service (and sshd) has started I can remotly log into the machine: the rpc.quotad has started but takes no CPU-time (so I guess he must be waiting for something)
Some other observations I had: - a restart of LDAP takes several minutes - if the LDAP-service is down a "su ldap" (ldap IS in /etc/passwd) seems to hang. The ldap-service-script does such a su to check the configuration so I guess that is what takes the service so long)
Could anyone give me a hint what the problem could be and how to fix it? Is any more information required (don't want to spam you with the nsswitch.conf and the whole pam.d-stuff)?
Bernhard
On Thu, 2008-10-02 at 17:08 +0200, Bernhard Gschaider wrote:
Hi!
I've got a CentOS4.7-machine as a fileserver. The machine also serves as the LDAP-server against which all regular users are authenticated. The problem I am having is that the machine takes a very long time to boot. Most of the services start up rather quick, but three services take quite a long time (extending the boot time to over half an hour, which is .... long)
The three services are (in that order):
- NFS statd
- LDAP
- NFS quota
As soon as the LDAP-Service (and sshd) has started I can remotly log into the machine: the rpc.quotad has started but takes no CPU-time (so I guess he must be waiting for something)
Some other observations I had:
- a restart of LDAP takes several minutes
- if the LDAP-service is down a "su ldap" (ldap IS in /etc/passwd) seems to hang. The ldap-service-script does such a su to check the configuration so I guess that is what takes the service so long)
Could anyone give me a hint what the problem could be and how to fix it? Is any more information required (don't want to spam you with the nsswitch.conf and the whole pam.d-stuff)?
---- add this to the bottom of /etc/ldap.conf
timelimit 30 bind_timelimit 30 bind_policy soft nss_initgroups_ignoreusers root,ldap
Craig
On Thu, Oct 2, 2008 at 11:17, Craig White craigwhite@azapple.com wrote:
add this to the bottom of /etc/ldap.conf
timelimit 30 bind_timelimit 30 bind_policy soft nss_initgroups_ignoreusers root,ldap
Personally, I use a longer list or users: nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus
I've collected those in trying to speed up the startup of other daemons. I'm not sure if all of them are still relevant, but in any case I think it's a good idea to configure this for users that you know for sure they are in /etc/passwd and not in LDAP.
HTH, Filipe
On Thu, Oct 02, 2008 at 12:25:55PM -0400, Filipe Brandenburger wrote:
Personally, I use a longer list or users: nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus
I've collected those in trying to speed up the startup of other daemons. I'm not sure if all of them are still relevant, but in any case I think it's a good idea to configure this for users that you know for sure they are in /etc/passwd and not in LDAP.
Or maybe just for local system accounts with uid < 100 ?
This would return that list:
awk -F: '$3<100 { a = a "," $1} END { a=substr(a,2) ; print a}' /etc/passwd
On Thu, 2 Oct 2008 12:25:55 -0400 "FB" == Filipe Brandenburger filbranden@gmail.com wrote:
FB> On Thu, Oct 2, 2008 at 11:17, Craig White FB> craigwhite@azapple.com wrote: >> add this to the bottom of /etc/ldap.conf >> >> timelimit 30 bind_timelimit 30 bind_policy soft >> nss_initgroups_ignoreusers root,ldap
FB> Personally, I use a longer list or users: FB> nss_initgroups_ignoreusers FB> root,ldap,named,avahi,haldaemon,dbus
FB> I've collected those in trying to speed up the startup of FB> other daemons. I'm not sure if all of them are still relevant, FB> but in any case I think it's a good idea to configure this for FB> users that you know for sure they are in /etc/passwd and not FB> in LDAP.
Thanks to everyone who answered in this thread. This did the trick. (I took the longer variation that Filipe suggested, didn't care to experiment whether I could shorten that list)
Bernhard
-
Bernhard Gschaider -
Craig White -
Filipe Brandenburger -
Stephen Harris