Bug 49549 – restore umask - Check_univention_replication fails after some time (/var/lib/univention-directory-listener/notifier_id: Permission denied)

Bug 49549 - restore umask - Check_univention_replication fails after some time (/var/lib/univention-directory-listener/notifier_id: Permission denied)


Summary:	restore umask - Check_univention_replication fails after some time (/var/lib/...

Status:	RESOLVED WONTFIX

Product:	UCS
Classification:	Unclassified
Component:	Listener (univention-directory-listener)
Version:	UCS 4.3
Hardware:	Other Linux

Importance:	P5 normal (vote)
Target Milestone:	---
Assigned To:	UCS maintainers
QA Contact:	UCS maintainers

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2019-05-24 14:12 CEST by Robert Zöhrer
Modified:	2021-05-14 16:34 CEST (History)
CC List:	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:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:

Attachments
Add an attachment (proposed patch, testcase, etc.)

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

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().

Comment 2 Ingo Steuwer

2021-05-14 15:43:18 CEST

This issue has been filed against UCS 4.3.

UCS 4.3 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed.

If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.