Univention Bugzilla – Bug 49459
multiple locks in UCS_LOCK table for one object
Last modified: 2019-11-19 21:15:23 CET
+++ This bug was initially created as a clone of Bug #42821 +++ I a customer environment the UCS_LOCK table in the sqlite locking database had several (> 2500) entries for one object. No additional information available, except it was a rejected object from s4, but we may have a problem releasing the locks. I encountered the same problem in a customer environment. Now UCS 4.4 e90 with dns legacy mode. It is save to delete these locks? I removed the reject already.
If you remove rejects * you habe to manually make sure that the affected object is in sync. Otherwise it will be out of sync. * Possibly locks are not cleaned up. I'm not familiar with that code. My first step would be to see, what purpose a thing like this has. Like this: =================================================================================================================================================== arequate@braeda:~/git/ucs/services/univention-s4-connector on 4.4-0 [?$] $ grep -r UCS_LOCK . ./modules/univention/s4connector/lockingdb.py: ("INSERT INTO UCS_LOCK(uuid) VALUES(?);", (str(uuid),)) ./modules/univention/s4connector/lockingdb.py: ("DELETE FROM UCS_LOCK WHERE uuid = ?;", (str(uuid),)) ./modules/univention/s4connector/lockingdb.py: ("SELECT id FROM UCS_LOCK WHERE uuid=?;", (str(uuid),)) ./modules/univention/s4connector/lockingdb.py: "CREATE TABLE IF NOT EXISTS UCS_LOCK (id INTEGER PRIMARY KEY, uuid TEXT);", $ git log ./modules/univention/s4connector/lockingdb.py | tail1 commit a9c5e66f39 Author: Stefan Gohmann <gohmann@univention.de> Date: Wed Sep 3 14:23:54 2014 +0000 * Added a locking table to avoid overwrites from objects which have been synchronized half (Bug #35391) git-svn-id: svn+ssh://billy.knut.univention.de/var/univention/svn/dev/branches/ucs-4.0/ucs-4.0-0@53306 1b283449-9f2f-0410-b571-8eb228e1a901 =================================================================================================================================================== So, I guess, if a traceback has occurred, the object is "synchronized half" and you have a lock lying around. My impression is, that remove_ucs_rejected.py and remove_s4_rejected.py (created via Bug #32194) may need some adjustment. See also Bug #40415.
As a general rule it makes more sense to fix the cause of a reject, which allows the S4-Connector to sync the reject.
Again seen in Ticket# 2019060321000589: root@master:~# sqlite3 /etc/univention/connector/lockingdb.sqlite 'select * from UCS_LOCK where uuid="ea443bee-c80c-1031-9bf7-2dcebf1d0902"' | wc -l 249208 root@master:~# du -sh /etc/univention/connector/lockingdb.sqlite 984M /etc/univention/connector/lockingdb.sqlite All due to one rejected user.
*** Bug 49646 has been marked as a duplicate of this bug. ***
There is a trivial patch attached to Bug 49646.
(In reply to Arvid Requate from comment #5) > There is a trivial patch attached to Bug 49646. attachment 10062 [details]
50d4bcf844 | Fix 8dc9a2ed71 | Advisory
Commit was done with Bug Number #49646. univention-s4-connector (13.0.2-29) 50d4bcf844ad | Bug #49646: Stop adding an unlimited number of lock entries
Very nice, my file was also full of duplications: root@master100:~# sqlite3 /etc/univention/connector/lockingdb.sqlite 'select uuid from UCS_LOCK' | wc -l 606337 root@master100:~# sqlite3 /etc/univention/connector/lockingdb.sqlite 'select distinct uuid from UCS_LOCK' | wc -l 23
<http://errata.software-univention.de/ucs/4.4/239.html>