我们使用 LDAP 作为 drupal 站点的后端用户数据库（drupal 从中读取/写入）。LDAP 已经运行了数周，但由于某种原因，它今天停止运行了。我使用以下命令查看系统日志：
$ grep -i "error\|panic\|unable\|warning\|fatal\|issue" /var/log/syslog | grep slapd
出现的第一个错误是这些：
Sep 20 09:59:38 server slapd[18158]: bdb(dc=example,dc=org): PANIC: fatal region error detected; run recovery
Sep 20 09:59:38 server slapd[18158]: conn=1010 op=7 RESULT tag=107 err=80 text=internal error
问题 1：有没有办法进一步找出导致该问题的原因fatal region error？（也许 drupal 的 ldap 模块发出了 openldap 不喜欢的命令）。
根据错误消息的建议，我运行了恢复工具：
$ sudo /etc/init.d/slapd stop
$ sudo /usr/bin/db4.7_recover -v -h /var/lib/ldap/
Finding last valid log LSN: file: 3916 offset 298418
Recovery starting from [3916][298273]
Recovery complete at Tue Sep 20 12:17:42 2011
Maximum transaction ID 80000017 Recovery checkpoint [3916][298418]
$ sudo /etc/init.d/slapd start
我接下来在系统日志中看到的内容是：
Sep 20 12:17:47 server slapd[10286]: @(#) $OpenLDAP: slapd 2.4.21 (Jun 2 2011 19:36:19) $#012#011buildd@allspice:/build/buildd/openldap-2.4.21/debian/build/servers/slapd47
Sep 20 12:17:47 server slapd[10286]: PROXIED attributeDescription "DC" inserted.
Sep 20 12:17:48 server slapd[10287]: bdb(dc=example,dc=org): /var/lib/ldap/log.0000003916: log file unreadable: Permission denied <----- HERE
Sep 20 12:17:48 server slapd[10287]: bdb(dc=example,dc=org): PANIC: Permission denied
Sep 20 12:17:48 server slapd[10287]: bdb(dc=example,dc=org): Invalid log file: log.0000003916: DB_RUNRECOVERY: Fatal error, run database recovery
Sep 20 12:17:48 server slapd[10287]: bdb(dc=example,dc=org): PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
发生的情况是，其中一个日志文件无法被 slapd 读取，因为所有者确实从 openldap 更改为 root，并且权限设置为 600：
/var/lib/ldap/log.0000003916: log file unreadable: Permission denied
$ sudo ls -lh /var/lib/ldap/
-rw------- 1 openldap openldap 10M 2011-09-09 11:09 log.0000003914
-rw------- 1 openldap openldap 10M 2011-09-20 09:54 log.0000003915
-rw------- 1 root root 10M 2011-09-20 12:10 log.0000003916 <----- HERE
-rwxr-xr-x 1 openldap openldap 20M 2011-09-20 12:51 mail.bdb
-rwxr-xr-x 1 openldap openldap 1.7M 2011-09-20 12:51 objectClass.bdb
-rwxr-xr-x 1 openldap openldap 12M 2011-09-20 12:51 sn.bdb
-rwxr-xr-x 1 openldap openldap 1.4M 2011-09-20 12:51 uid.bdb
我通过将所有者从 root 更改为 openldap 来解决了此问题：
$ sudo chown openldap:openldap /var/lib/ldap/log.0000003916
然后 slapd 正常启动：
Sep 20 13:01:40 evergreen slapd[18901]: @(#) $OpenLDAP: slapd 2.4.21 (Jun 2 2011 19:36:19) $#012#011buildd@allspice:/build/buildd/openldap-2.4.21/debian/build/servers/slapd
Sep 20 13:01:40 evergreen slapd[18901]: PROXIED attributeDescription "DC" inserted.
Sep 20 13:01:41 evergreen slapd[18902]: slapd starting
我在运行之前没有检查该日志文件的权限db4.7_recover，所以我不知道将所有者设置为 root 的原因。
Q2：是否建议db4.7_recover以 openldap 身份运行以避免日志文件的权限问题（例如，执行 sudo -u openldap /usr/bin/db4.7_recover -v -h /var/lib/ldap）？
Q3：一个更普遍的问题：有没有办法监视哪个进程最后更改了文件的权限？（这样，如果问题不在于db4.7_recover以 sudo 身份运行，我就能找出问题所在）。
Q4：您对如何解决此类 LDAP 问题还有更多建议吗？
附加信息：
-server = ubuntu 10.04
-openldap =https://help.ubuntu.com/community/OpenLDAPServer
答案1
在繁忙的服务器上，我发现 OpenLDAP 默认的最大文件句柄数为 1024，存在问题。在 /etc/security/limits.conf 中为 openldap 用户增加该限制，看看是否能解决问题。通常，如果这是原因，slapd 会将其写入日志。
在某些情况下，slapd 还可能随着时间的推移而泄漏内存，因此 Linux 内核 OOM 会将其杀死。如果发生这种情况，dmesg 应该会告诉您内存不足杀手如何勇敢地杀死 slapd。
Q2：只要在启动 slapd 之前修复权限，就没问题。
Q3：Linux 审计子系统可以帮助您。阅读 man auditd 和 auditctl；回答这个问题超出了您原始问题的范围 :)
Q4：将 slapd 日志级别增加到最大，阅读日志。谷歌。