最近需要在我们的一台服务器上重新启动OpenLDAP。 当我重新启动服务时，命令提示符只是坐在那里等待一些东西。 我从来没有得到[ OK ] 。 如果我CTRL+C出来，它说
...killed. /etc/openldap/cacerts/company.crt is not readable by "ldap[WARNING]
为了certificate一点，我recursion地创build了/etc/openldap 777。 我仍然得到错误。
我没有看到/var/log任何内容改变，给我一些反馈。 我需要什么来解决这个问题？
这是一个运行Fedora 8的旧服务器（我知道，责备以前的IT人员）。
这里有一些额外的debugging的想法。 这些都是必要的，如果你绝对肯定这不是一个权限问题…
首先，尝试在debugging模式下运行slapd：
slapd -u ldap -g ldap -d 65
请注意，-d的参数是一个位域，可以在slapd.conf手册页中find它的值（查找loglevel ）。 65是trace + config，对于这类问题通常是非常详细的。 这可能会或可能不会告诉你任何有用的东西。
如果这不起作用，我们可以使用strace （一个系统调用跟踪器）来确定发生了什么事情。 像这样运行slapd ：
strace -o /tmp/trace -f -s 1024 slapd -u ldap -g ldap -d 7
当它死亡时，你将有一个文件/tmp/trace包含来自slapd所有系统调用。 好奇-f让strace跟随分叉（在这种情况下并不是真正必要的，但这是我的默认设置），而-s 1024使strace在跟踪日志中打印多达1024字节的string参数。
现在，使用grep在这个文件中查找对company.crt引用。 从理论上讲，如果他们是一个权限问题，你会发现这样的东西：
open("/tmp/company.crt", O_RDONLY) = -1 EACCES (Permission denied)
或者像这样的东西，如果文件丢失：
open("/tmp/company.crt", O_RDONLY) = -1 ENOENT (No such file or directory)
一个成功的开放看起来像这样：
open("/tmp/company.crt", O_RDONLY) = 3
在那里3是由open打开的文件描述符（也可能是其他正整数）。
看看是否有明显的东西跳出来。 让我知道如果这没有帮助。
您不应该将/ etc / openldap设置为777.权限对于使事情有时正常工作是必需的。 我build议把它改回到755。
您可能对cacerts有不正确的用户和/或权限
drwxr-xr-x 3 root root 4096 Apr 19 2007 cacerts /