Univention-directory-notifier crash after upgrade to 4.3-4

Hello, the univention-directory-notifier die with:

2019-06-20 13:08:37,487:CRITICAL:ldap_search(reqSession=0,cn=translog): No such object
Traceback (most recent call last):
  File "/usr/share/univention-directory-notifier/univention-translog", line 1178, in <module>
    exit(main())
  File "/usr/share/univention-directory-notifier/univention-translog", line 398, in main
    return opt.func(opt) or 0
  File "/usr/share/univention-directory-notifier/univention-translog", line 442, in import_all
    with Index(opt.translog_file) as index, Translog(opt.translog_file, index) as translog, ldapi(opt) as ld:
  File "/usr/share/univention-directory-notifier/univention-translog", line 284, in __enter__
    assert last <= rec.tid, (last, rec.tid)
AssertionError: (293192, 0)

please help.

Interesting. Please post the output of the following commands:

ldapsearch -H ldapi:// -x -b cn=translog | grep numEntries
grep translog /etc/ldap/slapd.conf
univention-check-templates
# ldapsearch -H ldapi:// -x -b cn=translog | grep numEntries
# numEntries: 168130

# grep translog /etc/ldap/slapd.conf
#       /etc/univention/templates/files/etc/ldap/slapd.conf.d/99translog
moduleload      translog.so
overlay         translog
translog        /var/lib/univention-ldap/listener/listener
### cn=translog backend
suffix  "cn=translog"
directory       "/var/lib/univention-ldap/translog"

# univention-check-templates
WARNING: The following UCR files are modified locally.
Updated versions will be named FILENAME.dpkg-*.
The files should be checked for differences.

/etc/univention/templates/files/etc/nagios/nrpe.cfg

It sounds like your transaction log file is corrupt, or at least it contains lines where the running number isn’t correct (it should be the previous running number +1, but it seems to be 0 for at least one line). See this article for ways to debug transaction log problems.

Thank you very much, following the link I got to the point where I need to resynchronize the backup:

Thanks again.

Hello, the univention-join failed with:

Waiting for activation of the extension object msgpo:…ERROR: Master did not mark the extension object active within 180 seconds.
ERROR
ucs_registerLDAPExtension: registraton of /usr/share/univention-s4-connector/ldap/msgpo.schema failed.

Make sure the directory notifier & the directory listener services are running.

Also check the system diagnostics (log in to the UMC → System → System diagnostics).

Hi, yes they are on both:

[root@ucsdc ~]# ps ax|grep univention-directory-listener
  464 ?        Ss     0:00 runsv univention-directory-listener
12146 ?        S      0:02 /usr/sbin/univention-directory-listener -F -d 2 -b dc=mydomain,dc=it -m /usr/lib/univention-directory-listener/system -c /var/lib/univention-directory-listener -ZZ -x -D cn=admin,dc=mydomain,dc=it -y /etc/ldap.secret

[root@ucsdc ~]# ps ax|grep univention-directory-notif
  465 ?        Ss     0:08 runsv univention-directory-notifier
12089 ?        S      0:00 /usr/sbin/univention-directory-notifier -o -d 1 -v 2 -F

[root@ucsbc ~]# ps ax|grep /univention-directory-noti
 1095 ?        S      0:00 /usr/sbin/univention-directory-notifier -o -d 1 -v 2 -F

[root@ucsbc univention]# ps ax|grep /univention-directory-listener
 1157 ?        S      0:04 /usr/sbin/univention-directory-listener -F -d 2 -b dc=mydomain,dc=it -m /usr/lib/univention-directory-listener/system -c /var/lib/univention-directory-listener -o -ZZ -x -D cn=admin,dc=mydomain,dc=it -y /etc/ldap.secret

on master:

$ univention-directory-listener-ctrl status
Listener status:
 run: univention-directory-listener: (pid 12146) 46102s, normally down

Current Notifier ID on "ucsdc.mydomain.it"
 **326**

Last Notifier ID processed by local Listener:
 **291135**

Last transaction processed:
 326 cn=container/msgpo,cn=udm_module,cn=univention,dc=mydomain,dc=it m

The current notifier ID is lower than the last notifier ID processed by the listener? That’s not good. With each change to the LDAP the notifier ID is incremented, and the listener then retrieves those changes by comparing its ID with the new notifier ID and fetching only the needed changes. This also means that the notifier ID is normally always >= the listener ID (if they’re equal, all pending changes have been processed by the listener).

This isn’t the case for you, and that means that something’s seriously broken in your setup, e.g. the whole transaction logging is off. I would expect to see serious issues such as existing transactions being overwritten, the listener not ever retrieving those changes (because its ID is so much higher than the notifier’s ID)…

I honestly don’t think I can help you simply via the forum. If you have a valid license (and are thereby entitled to support) I highly suggest contacting their support. If you don’t, you might want to think about purchasing a license or support.

Hi, can I remove the backup dc then reset the transaction log ? or I need to reconstruct all that data?

thnx.

Hi, thanks to backups I rolled back, now I’m testing in lab the upgrade.

Hi, updated to 4.4 instead of 4.3-4 without problems.

Mastodon