Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My mac server's processors are showing 100% on all the four processors. I am running server 10.5.8 and this server is the master LDAP controller

Looking at the activity monitor, I find that the process 'slapd' is hogging all processing time

What could be the issue here

share|improve this question
That your LDAP process is hogging the process? – Bart Silverstrim Sep 7 '10 at 11:20
Did you look in the logs for possible error messages? Hard drive issue? Database corruption? Network interface being flooded with requests? Are you having users unable to log in or get authenticated? – Bart Silverstrim Sep 7 '10 at 11:21

May have a corrupt ldap db. Try the following. Of course make sure you have a good backup..etc.

Syslog Error: org.openldap.slapd throttling respawn...

launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist

cd /var/db/openldap/openldap-data/

db_recover -c


share|improve this answer

Is SSH/port 22 exposed to the internet, or on a system connected to the LDAP service? With 10.4 this was a good way for a DOS because answering all the invalid login attempts coming up would slow the system to a crawl. I never knew why this would slow down things so much, but it did and I couldn't to anything about it.

I never tried this with 10.5 or 10.6, so this might not apply here.

share|improve this answer
The thread… can help prevent this kind of issue, should it actually be the cause – gWaldo Sep 7 '10 at 13:20

Every time I've seen slapd consume any serious amount of CPU (though on Linux), it's been due some missing indexes. Have you configured indexes for your LDAP databases?

share|improve this answer
Normally, all the indexes necessary to work as an Open Directory server should exist by default. – Sven Sep 7 '10 at 11:24
Normally. Gatura didn't tell us if there are any custom LDAP schemas in use etc. My best bet is still that this issue is due some missing indexes. – Janne Pikkarainen Sep 7 '10 at 11:27

I've had this happen, too. In my case, it was a AFP (Mac file sharing) based home directory server and an Open Directory Replica. I ended up reinstalling the OS and re-binding it to the OD Master. Nothing else seemed to work. Not disk repair tools (fsck, diskutil, Disk Warrior), or re-binding to the OD Master, or software updates, or checking the logs, or calling Apple more than a half-dozen times.

If this is your Open Directory Master, export all your users, user groups, computers, and computer groups via Workgroup Manager. Then demote all OD Replicas to Stand Alone and reboot them. Then re-import the Workgroup Manager data and re-bind the Replicas. (Note that all users' passwords will be lost. You can use the shareware program Passanger to read the users export and re-write it with known passwords. Then distribute the passwords to your users.) This process will cause the Open Directory data to rebuild, which should remove the corruption in an OD Master. Yes, I've had to do this a few times before. My users were... unhappy about the experience. They were glad that they could login again, though.

If your server is at a school, don't forget that Apple provides free phone support.

Good luck.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.