[collectd] RFC: implementing reload/reconfigure (was: New aggregator plugin "basic_aggregator" (#136))
ymettier at free.fr
Mon Oct 15 09:40:09 CEST 2012
> Now, when thinking about a "reconfig" operation, most plugins will
> probably de-configure and re-read the new configuration (possibly
> leaving some caches or certain state-information in place).
> this would not work if there are more than one <Plugin> blocks. I.e.,
> plugin would behave differently when being configured and when being
Some do not read more than one config block (I don't remember which one
I found recently).
About this, I have a question (that should maybe be discussed in
another thread) : I have a generic config file. How do I do with
specific configurations ?
One solution is to have a centralized configuration (and deploy it with
puppet or some similar tool).
Another solution would be to have a generic configuration file and
another file that override the definitions of the generic one.
Why do I say that here ? Because the "Include" directive already
exists, and if you decide to take into account one and only one <plugin>
block (and define if you take the first or the last one), this should be
the solution to my problem. I "include" the specific configuration file
at the right place (first or last line in the configuration file) and
any <plugin> block in the included file will override the block in the
Yes, if possible, make that only one <plugin> block is read for one
> The question is if this should be considered at all (after all, it's
> officially supported). However, by splitting the "reconfig" into
> "deconfig" and "reconfig" (or "config"), we could easily handle this
> situation as well. So, I suggest the following:
> - typedef int (*deconfig_cb) (void);
> - typedef int (*reconfig_cb) (oconfig_item_t *);
> That is, 'deconfig' would use the same signature as 'shutdown' and
> 'reconfig' would use the same signature as 'config'. This would allow
> use the appropriate callbacks twice, which in most cases should be
> sufficient (probably plus some checks for current settings).
I understand what a a deconfig_cb would do, is useful to distinguish
the 2 sections <free the memory> and <allocate memory for configuration
But what do you want to do with a deconfig_cb() without a reconfig_cb()
And what is the difference between the config_cb() (the one that
already exists) and reconfig_cb() ?
> Any thoughts, comments on this?
>> As a second step we could then think about also implementing a
>> action. This would mean unloading and reloading the shared object of
>> plugin and then doing a "reconfigure".
> In fact, thinking about this again, I think that a global reload
> not unload and re-load the shared objects (but possibly unload
> that are no longer used and load new plugins). Else, it's gonna be
> to keep plugin-global information (caches, etc.) in place.
About the local allocated memory, how can you ensure that everything is
freed at unload time ? Only on the developer's responsibility ?
> However, a second operation (available through the 'unixsock' plugin
> similar) could be used for that case if anybody comes up with a
> for that.
Thinking about my recent jsonrpc plugin (already usable but not yet
finished), do you think that it will share functions with unixsock ?
Like deconfig/reconfig, unload/reload... ?
- Homepage - http://ymettier.free.fr
- GPG key - http://ymettier.free.fr/gpg.txt
- C en action - http://ymettier.free.fr/livres/C_en_action_ed2.html
- Guide Survie C - http://www.pearson.fr/livre/?GCOI=27440100673730
More information about the collectd