Troubleshooting: Listener-/Notifier

Note: For further details about troubleshooting check this article.

Listener-/Notifier replication

When the domain replication is running normally (normal system load, no network problems), the delay between the change being made in Univention Management Console and replicated to, for example, a slave domain controller is barely noticeable. An incomplete replication can be identified by comparing the transaction IDs of the listener and notifier services.

The transactions registered by the notifier service are written in the /var/lib/univention-ldap/notify/transaction file in ascending order on the master domain controller. An example:

root@dcmaster:~# tail -1 /var/lib/univention-ldap/notify/transaction
836 cn=dcslave3,cn=dc,cn=computers,dc=firma,dc=de m

The last transaction received by the listener system is stored in the /var/lib/univention-directory-listener/notifier\id file:

root@dcslave1:~# cat /var/lib/univention-directory-listener/notifier_id
836

In short, you can also use a preconfigures nagios check for this:

/usr/lib/nagios/plugins/check_univention_replication

Since UCS 4.1-3 there is also the possibilty to use:

univention-directory-listener-ctrl status

to get a quite complete overview of the Listener- / Notifier Replication status.

Mastodon