Univention Bugzilla – Bug 35173
ldap-group-to-file may run multiple times
Last modified: 2020-04-14 18:09:20 CEST
If ldap-group-to-file takes very long, it may be startet multiple times by cron. I think a second process should be prohibited.
Reported again via Ticket#2014102021000413
Reported again (for UCS 4): 2015090321000536
There is a Customer ID set so I set the flag "Enterprise Customer affected".
This issue has been filled against UCS 4.0. The maintenance with bug and security fixes for UCS 4.0 has ended on 31st of May 2016. Customers still on UCS 4.0 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.
Created attachment 10119 [details] patch (git:fbest/35173-lock-ldap-group-to-file) Attached is a patch which adds a simple locking mechanism via a file in /var/run. Reproducible via: echo -en '#!/usr/bin/python\nimport time; time.sleep(1000)' > /var/lib/ldap-group-to-file-hooks.d/sleep.py chmod +x /var/lib/ldap-group-to-file-hooks.d/sleep.py
I'd put the _lock into the try/except to reduce the possibility of leaving a lock behind when the process gets killed at the wrong time. Also, I'd use lockf (which we use in the listener, or instead flock) to avoid stale locks. See http://0pointer.de/blog/projects/locking.html though.
Yes, thanks!
The patch has been adjusted to use univention.lib.locking which uses fcntl.lockf(). univention-pam (12.0.2-2) c5d171f66ca7 | Bug #35173: add locking for ldap-group-to-file univention-pam.yaml b55abe78e5cd | YAML Bug #35173
Verified: * code review * functional test (lock file: /var/run/ldap-group-to-file.pid) * advisory
<http://errata.software-univention.de/ucs/4.4/191.html>