[collectd] RFC: implementing reload/reconfigure (was: New aggregator plugin "basic_aggregator" (#136))
ymettier at free.fr
Tue Oct 23 10:35:28 CEST 2012
Today, I'm working on the nfs plugin (adding stuff for
/proc/self/mountstats). And I thought that supporting reconfig would be
nice. So I'm reading this mail again...
Some new comments are here.
>> /* plugin.h */
>> int plugin_register_reconfig (const char *name,
>> int (*callback) (oconfig_item_t *));
>> /* UNIXSOCK */
>> RECONFIGURE <PluginName>
> 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:
Having deconfig + reconfig is definitely a good idea because the
developer has to think how to "free" the memory allocated with
config/reconfig and cannot produce bad code with fastly coded
> - 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 like typedef int (*reconfig_cb) (oconfig_item_t *);
Because of the same signature as 'config'. But in reality because of
the signature of "config_complex".
What about "config simple" ?
In my mind, most plugins will have the same callback for config and
reconfig. So I suggest :
- typedef int (*deconfig_cb) (void);
- typedef int (*reconfig_cb) (const char *key, const char *value);
- typedef int (*reconfig_complex_cb) (oconfig_item_t *);
About the nfs plugin (currenly having no configuration at all, I will
choose the config_complex mechanism) and will try to support these
definitions (and hack something with stat() again before all this is
> 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.
> However, a second operation (available through the 'unixsock' plugin
> similar) could be used for that case if anybody comes up with a
> for that.
> collectd mailing list
> collectd at verplant.org
- 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