Bug 49817 - Check whether a resync is already in progress before starting another one
Check whether a resync is already in progress before starting another one
Status: NEW
Product: UCS
Classification: Unclassified
Component: Listener (univention-directory-listener)
UCS 4.4
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-07-05 13:57 CEST by Valentin Heidelberger
Modified: 2019-07-11 12:55 CEST (History)
2 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 2: Improvement: Would be a product improvement
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.023
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 Valentin Heidelberger univentionstaff 2019-07-05 13:57:49 CEST
univention-directory-listener-ctrl allows users to start multiple concurrent resyncs, which can cause problems. One problem that I can reproduce regularly is that the second resync runs forever but phahn hinted that their could be even worse problems if the second resync cancels the first in a bad moment.

Imho univention-directory-listener-ctrl should check whether a resync is already in progress when it's invoked to start one. I've built very simple logic doing that in the past to work around this problem. In that case I just set a UCR var when the resync was started and unset it when it was done. There are certainly more elegant ways to accomplish that.

The documentation also doesn't tell the user that concurrent resyncs are not a good idea/not supported by the listener.
https://docs.software-univention.de/manual-4.4.html#domain:listenernotifier:erroranalysis:reinit

I'll open a separate bug for that now but if it's decided to "just" fix this behaviour that bug can be closed.
Comment 2 Ingo Steuwer univentionstaff 2019-07-05 16:02:23 CEST
Some thoughts:

* this behavior is in UCS since the first release. I can't remember customers complaining about it.

* this is an expert tool for special "problem solving" use cases, and I think it's obvious that it should be "handled with care"

* I doubt that there is a simple solution: the resync process is an initialization of the listener plugin, which is individually implemented as part of the plugin. There are plugins that just write information to APIs / files which are processed "later". You can't fully control this.

I'd like to close this bug and keep the documentation.
Comment 3 Valentin Heidelberger univentionstaff 2019-07-05 16:09:24 CEST
(In reply to Ingo Steuwer from comment #2)
> * I doubt that there is a simple solution: the resync process is an
> initialization of the listener plugin, which is individually implemented as
> part of the plugin. There are plugins that just write information to APIs /
> files which are processed "later". You can't fully control this.
> 
> I'd like to close this bug and keep the documentation.

I see your point regarding external factors we have no control over (APIs, etc. spoken to by listener modules). I agree, we shouldn't try to control what happens there in a resync. What I'm currently thinking of changing is only what happens in the listener itself - if the listener module takes hours to complete after a resync and one breaks something by triggering a new resync after half an hour - that isn't our problem. However, if the listener itself runs into problems by triggering resyncs we should change it so that that can't happen.