Description Erik Damrose 2023-05-17 18:00:20 CEST

Initializing or reinitializing a listener module in a domain with many affected objects can take a long time, because all matching objects are fetched from LDAP and passed to the module. The duration can also be longer if an external service is contacted by the listener module, e.g. in the MS365 connector.

Problem: If a logrotate happens during that time, the listener module progess cannot be followed in the listener.log, there are no new entries in the file. It seems like the listener is hanging, although it is still processing entries. One might suspect something is wrong and restart the listener, which will only restart the module initialization from the start.

The reason is, that signal processing is deactivated while initializing the listener. The listener also currently handles the initialization as one atomic event and will start from scratch after it is restarted, which is what the logrotate config is trying to do.

management/univention-directory-listener/src/main.c has this in main():

/* XXX: we shouldn't block all signals for so long */
signals_block();
[...]
handlers_init();
[...]
signals_unblock();

After the logrotate, you can see the listener process logging into a deleted file:
$ lsof -p <listener-pid>
univentio 2047 listener    1w   REG  253,0    27130 1309466 /var/log/univention/listener.log.1 (deleted)
univentio 2047 listener    2w   REG  253,0    27130 1309466 /var/log/univention/listener.log.1 (deleted)