Quoting sgmayo@mail.bloomfield.k12.mo.us:
Quanah Gibson-Mount wrote:No amount of adjusting the loglevel in slapd.conf/slapd-config is going to help you get information on why slapd won't start if it never gets far enough to open syslog. Which is why I've suggested using slapd level debugging.Well..you were right. The '-1' got me a bit more info. :)
Quanah is correct, of course; if slapd keeps dying before it can ever write anything to a log, adjusting the loglevel won't help.
Here is what it says, I am guessing that this means it is up and listening alright.
If it's up, you should be able to see it with something like "ps ax". If you can see it, test that it's listening with "nmap localhost" (the output should include something like "389/tcp open ldap"). If it's listening, test if it responds to queries like "ldapsearch -x -LLL".
Also, even without slapd running, does the output from "slapcat" show anything familiar? If so, your database may not be the problem (if it is anyway, perhaps simply re-indexing would fix things, but that's more of a guess).
I've also just learned that Fedora doesn't maintain a /var/log/syslog by default. If you want to know where usual standard log outputs are being sent, check your log configuration (/etc/syslog.conf, or /etc/rsyslog.conf, or whatever it is on Fedora). With Debian, the stuff that slapd sends to my syslog is because of this line in /etc/rsyslog.conf:
*.*;auth,authpriv.none -/var/log/syslog
Thinking more broadly, have you checked that all of the server's
filesystems were mounted properly after booting up? Or, if they're all
mounted, maybe one critical to slapd is read-only, or has no free
space for some reason.
Cheers, Jaap