Problem: Empty failed ldif could not be removed

[scheinig]

Problem:

Empty failed.ldif could not be removed.
For example on a slave you see in
/var/log/univention/listener.log
that you have a failed.ldif

Investigation:

You troubleshoot with

What to do if a failed.ldif is found

Problem: Each UCS system is running an instance of the Univention Directory Listener. The Univention Directory Listener is the counterpart to the Univention Directory Notifier which only runs at the DC Master and DC Backups. The notifier monitors changes in the LDAP directory and makes these changes available for listener instances at each other system - these sent changes are called transactions (see UCS manual: Listener/Notifier replication workflow). Inside the listener the module replicat…

Problem: Troubleshooting slapd during an failed.ldif import

Problem: A failed.ldif is found on your server. You may know this article from the past. Since the introduction of systemd, there might be complications following the article from above. So try the following steps to reread the failed.ldif Step 1 Check the slapd status systemctl status slapd.service If this looks like this: Active: active (running) root@master:~# systemctl status slapd.service ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) …

but the failed.ldif is empty and pops up again after removing.

Solution:

Switch to the mdb backend for ldap, if you are still using the bdb backend.
ucr get ldap/database/type
http://docs.software-univention.de/performance-guide-5.0.html#slapd:bdb

/etc/init.d/slapd stop
slapcat -l ldif
mkdir /var/lib/univention-ldap/ldap.BACKUP
mv /var/lib/univention-ldap/ldap/* /var/lib/univention-ldap/ldap.BACKUP
ucr set ldap/database/type=mdb
slapadd -l ldif
systemctl daemon-reload
/etc/init.d/slapd start