Hi, On Wed, Oct 10, 2012 at 11:28:05PM -0700, ymettier wrote: > After some use of the aggregator, I noticed that when you change > something in the configuration of the aggregator (add,remove a > hostname, type...), you have to restart all collectd to take the > change into account. > > This new commit introduce a new feature : there is a distinct > configuration file for the aggregator and when it changes, the > aggregator notices it and updates its configuration. No more need to > restart anything.
Hrm, from a first glance, I don't really like this idea. The following are a couple of random ideas / notes; maybe we can get to a "better" (more generic) solution from there. Also, I've Cc'ed the mailing list. Imho, the discussion should happen there. Background: currently, collectd does not support reloading any configuration at run-time. This is due mostly to the rather generic configuration approach. Support for config reloading would probably require modifying each single plugin. Now, my idea is to introduce a "reconfigure" callback that allows to reconfigure a single plugin. This could then be exposed, for example, through the 'unixsock' plugin. Example: /* plugin.h */ int plugin_register_reconfig (const char *name, int (*callback) (oconfig_item_t *)); /* UNIXSOCK */ RECONFIGURE <PluginName> Obviously, "reconfigure" will fail if the specified plugin did not register a "reconfig" callback. In case, the plugin did not specify a "config" callback either, "reconfigure" could be a no-op (no error). Internally, the callback would trigger re-parsing the whole collectd.conf file. Then, the appropriate config-block would be dispatched to the registered "reconfig" callback just in the same way that the original configuration was dispatched to the "config" callback. As a second step we could then think about also implementing a "reload" action. This would mean unloading and reloading the shared object of a plugin and then doing a "reconfigure". This approach will allow us to introduce a global "reload" operation step by step. Also, if we decide never to implement a global operation, some plugins (like the aggregator) will still be able to benefit from the infrastructure. What do others think? Cheers, Sebastian -- Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin _______________________________________________ collectd mailing list collectd@verplant.org http://mailman.verplant.org/listinfo/collectd