LDAP, умирающий по неизвестным причинам
Я думаю, что Вы делаете это назад: dev должен быть то, где Вы ударяете по вещам, заставьте его работать, который затем способствуется подготовке для тестирования - если это передает Ваше тестирование (регрессия, приемлемость для пользователя, и т.д.), Вы развертываетесь к своему рабочему серверу. Теперь, потому что вещи вне ненормального, почему не только делают Медосмотр к Виртуальной Миграции Вашей производственной машины со свободными инструментами Standalone Converter и ESXI и делают Ваш dev, подготовку, и т.д. виртуальные машины на ESXI базирующийся прочь этого преобразования P2V? Таким образом, все Ваши серверы теперь идентичны, и у Вас есть начало с нуля. Хорошая вещь о VMs - Вы, может сделать снимки перед любым основным исправлением и откатывать, если/когда вещи идут не так, как надо.
На загруженных серверах я видел, как OpenLDAP имеет проблемы с обработчиками файлов по умолчанию 1024 max. Увеличьте это ограничение в /etc/security/limits.conf для пользователя openldap и посмотрите, решит ли это проблему. Обычно, если это причина, slapd будет жаловаться на это в журналы.
При определенных обстоятельствах slapd также может со временем утечка памяти, и в результате OOM ядра Linux убьет его. Если это произошло, dmesg расскажет вам историю о том, как киллер из памяти храбро убил slapd.
Q2: не имеет значения, если вы исправляете разрешения перед запуском slapd.
Q3: Подсистема аудита Linux может вам в этом помочь. Прочтите man auditd и auditctl; ответ на этот вопрос выходит за рамки вашего первоначального Q:)
Q4: Увеличьте уровень журнала slapd до максимума, прочтите журналы. Google.