Check_univention_replication fails after some time



On a regular base Icinga2 reports when running check_univention_replication on our Backup Domain Controller:
CRITICAL: no change of listener transaction id for last 10 checks (nid=6579 lid=cat: /var/lib/univention-directory-listener/notifier_id: Permission denied)

root@bdc:~# ls -l /var/lib/univention-directory-listener/notifier_id
-rw------- 1 listener nogroup 4 Jul 19 12:06 /var/lib/univention-directory-listener/notifier_id

When I restart the service with service univention-directory-listener restart the file is create with correct file permissions.

root@bdc:~# ls -l /var/lib/univention-directory-listener/notifier_id
-rw-r--r-- 1 listener nogroup 4 Jul 19 12:26 /var/lib/univention-directory-listener/notifier_id

But after couple of hours or days the problem returns.

Any ideas?


We had that before.
The solution in mentions the following:

With Bug #41261 fixed the file /var/lib/univention-directory-listener/notifier_id is now created newly and renamed after each transaction; thus the file now has the correct permissions since UCS-4.1-2 errata

You didnt mention the version you are using. This should be provided before it makes sense to dig in deeper.


The version is tagged on the thread.
The server was installed with 4.2 and upgraded to 4.3-1.

Yes, I found those bug report. But this behaves differently. The file is create correctly. And I can see that the mentioned bugfix is in place since the inode number changes each time the file is written. That’s what written in the fix description. The file is moved and recreated each time.

What happens in our case is, that after some time, over night or so, the permissions on this file changes to 600, as the ls before shows.

Are there any housekeeping jobs that UCS performs?
Cleaning up logfiles, checking permissions, …


I must admit that I didnt look at the tags. And looking at this I would say that it is less helpful as it doesnt even provide the number of the point release, not to mention the errata level.

In general it would be helpful if the steps “what have I already done to narrow down the issue” are mentioned in the first description. This helps to speed up the discussion.

There are housekeeping jobs triggered by cron but it is possible that this behavior is caused by the listener itself.

I dont know Icinga but I would expect that you should be able to figure out from their event log when the permission changes more or less exactly. With this information you could look at the files in /var/log/univention/ or the cronjobs (see /var/log/syslog) what might have caused the change.