Univention Bugzilla – Bug 49817
Check whether a resync is already in progress before starting another one
Last modified: 2019-07-11 12:55:35 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.
I'll open a separate bug for that now but if it's decided to "just" fix this behaviour that bug can be closed.
* 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.
(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.