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
-
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.
gWaldo : The thread http://serverfault.com/questions/174951/securing-ssh-server-against-bruteforcing/174962#174962 can help prevent this kind of issue, should it actually be the causeFrom SvenW -
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?SvenW : Normally, all the indexes necessary to work as an Open Directory server should exist by default.Janne Pikkarainen : 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.From Janne Pikkarainen -
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
reboot.
From Jason -
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.
From Data Scavenger
0 comments:
Post a Comment