Bug 49549 - restore umask - Check_univention_replication fails after some time (/var/lib/univention-directory-listener/notifier_id: Permission denied)
restore umask - Check_univention_replication fails after some time (/var/lib/...
Status: NEW
Product: UCS
Classification: Unclassified
Component: Listener (univention-directory-listener)
UCS 4.3
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-05-24 14:12 CEST by Robert Zöhrer
Modified: 2019-09-18 12:52 CEST (History)
3 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 3: Simply Wrong: The implementation doesn't match the docu
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 1: Nuisance – not a big deal but noticeable
User Pain: 0.034
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Zöhrer 2019-05-24 14:12:42 CEST
Exactly every 30 days there is the following error with the UCS Monitoring Check:

Service: UNIVENTION_REPLICATION
Additional Info:

CRITICAL: no change of listener transaction id for last 10 checks (nid=5320 lid=cat: /var/lib/univention-directory-listener/notifier_id: Permission denied)

And after manually systemctl restart univention-directory-listener.service

we get correct permissions and monitoring service RECOVERY.

Seems to have other causes than bug 31573, because the bug also occurs with a quite current version 4.3-4 errata504.

Also described & mentioned @ https://help.univention.com/t/check-univention-replication-fails-after-some-time/9282

TIA Robert
Comment 1 Philipp Hahn univentionstaff 2019-05-24 15:39:19 CEST
Can you please run the following command if the error occurs:

    grep Umask /proc/$(pgrep -f /usr/sbin/univention-directory-listener)/status

It will check the `umask` of the currently running UDL process. It should be `0022`.
It it is not some UDL module changed the umask to some other value and did not restore it back. We just experienced the same problem yesterday here internally at Univention with the *Bareos*¹ listener module. You can use the following command to have a look it such an obvious faulty UDL module exists:

    grep umask /usr/lib/univention-directory-listener/system/*

By restarting UDL the problem is fixed until the broken UDL modules runs again.

¹: `/usr/lib/univention-directory-listener/system/univention-bareos.py


@DEV: Similar to restoring the effective UID after running a UDL module we can also restore the umask().