Bug 49459 - multiple locks in UCS_LOCK table for one object
multiple locks in UCS_LOCK table for one object
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: S4 Connector
UCS 4.4
Other Linux
: P5 normal (vote)
: UCS 4.4-1-errata
Assigned To: Arvid Requate
Florian Best
:
: 49646 (view as bug list)
Depends on: 35391 42821
Blocks:
  Show dependency treegraph
 
Reported: 2019-05-13 11:10 CEST by Christina Scheinig
Modified: 2019-11-19 21:15 CET (History)
2 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?: 1: Will affect a very few installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.034
Enterprise Customer affected?: Yes
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2016103121000363, 2019040421000563, 2019060321000589
Bug group (optional):
Max CVSS v3 score:
requate: Patch_Available+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christina Scheinig univentionstaff 2019-05-13 11:10:47 CEST
+++ 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.
Comment 1 Arvid Requate univentionstaff 2019-05-13 17:36:41 CEST
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.
Comment 2 Arvid Requate univentionstaff 2019-05-13 19:11:31 CEST
As a general rule it makes more sense to fix the cause of a reject, which allows the S4-Connector to sync the reject.
Comment 3 Arvid Requate univentionstaff 2019-06-27 23:11:08 CEST
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.
Comment 4 Arvid Requate univentionstaff 2019-06-27 23:13:08 CEST
*** Bug 49646 has been marked as a duplicate of this bug. ***
Comment 5 Arvid Requate univentionstaff 2019-06-27 23:13:49 CEST
There is a trivial patch attached to Bug 49646.
Comment 6 Florian Best univentionstaff 2019-08-08 15:54:46 CEST
(In reply to Arvid Requate from comment #5)
> There is a trivial patch attached to Bug 49646.
attachment 10062 [details]
Comment 7 Arvid Requate univentionstaff 2019-08-08 16:35:32 CEST
50d4bcf844 | Fix
8dc9a2ed71 | Advisory
Comment 8 Florian Best univentionstaff 2019-08-08 17:48:55 CEST
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
Comment 9 Florian Best univentionstaff 2019-08-08 17:53:44 CEST
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
Comment 10 Arvid Requate univentionstaff 2019-08-22 15:30:00 CEST
<http://errata.software-univention.de/ucs/4.4/239.html>