Re: when does bind calls plugin_destroy ?
On Tue, Nov 29, 2022 at 12:08:30AM +, Marcus Kool wrote: > I see random behavior while I do the same test: start named with unmodified > config file with 2 views (each a plugin instance), run the same 40+ queries > and reconfigure. repeat: a few more queries and reconfigure > > 9.16.1 rarely sees plugin_destroy at first reconfigure, 40% at the second > reconfigure for the first time, 60% at the third reconfigure for the first > time. Thereafter, after each plugin_register there is a plugin_destroy. > > 9.18.9 never seen plugin_destroy at first reconfigure, may take up to 4 > reconfigures for plugin_destroy being called. Thereafter, after each > plugin_register there is a plugin_destroy. That does seem strange. My only guess is that somethng is holding on to a reference to the original view after the reconfig, and the view isn't destroyed until that last reference is released. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: when does bind calls plugin_destroy ?
On 28/11/2022 22:07, Evan Hunt wrote:
On Mon, Nov 28, 2022 at 12:53:16PM +, Marcus Kool wrote:
In a test setup there are two instances of the same plugin and everything
works as expected (plugin_register is called twice - once for each view).
However, "rndc reconfig" calls plugin_register again twice but does not call
plugin_destroy...
Are you sure it's not being run?
It is run, but...
I see random behavior while I do the same test: start named with unmodified config file with 2 views (each a plugin instance), run the same 40+ queries and reconfigure. repeat: a few more queries and
reconfigure
9.16.1 rarely sees plugin_destroy at first reconfigure, 40% at the second reconfigure for the first time, 60% at the third reconfigure for the first time. Thereafter, after each plugin_register there
is a plugin_destroy.
9.18.9 never seen plugin_destroy at first reconfigure, may take up to 4
reconfigures for plugin_destroy being called. Thereafter, after each
plugin_register there is a plugin_destroy.
So, does anyone know when plugin_destroy is called and perhaps how a plugin
can detect a reconfig is done and can deallocate resources for the plugins
registered at startup?
For each view, "rndc reconfig" is supposed to create and configure a new view,
move the zones from the old view to the new one, and then destroy the one.
The destroy function for the view should clean up plugins:
| if (view->plugins != NULL && view->plugins_free != NULL) {
| view->plugins_free(view->mctx, &view->plugins);
| }
view->plugins_free is a pointer to ns_plugins_free(), which calls
unload_plugin() for each plugin configured in the view, and that calls
the plugin_destroy() function defined in the module.
If you have the logging level set to debug(1), you should see "unloading
plugin" in your log file when this happens.
Yes, the "unloading plugin" matches the log messages of the plugin.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: when does bind calls plugin_destroy ?
On Mon, Nov 28, 2022 at 12:53:16PM +, Marcus Kool wrote:
> In a test setup there are two instances of the same plugin and everything
> works as expected (plugin_register is called twice - once for each view).
>
> However, "rndc reconfig" calls plugin_register again twice but does not call
> plugin_destroy...
Are you sure it's not being run?
> So, does anyone know when plugin_destroy is called and perhaps how a plugin
> can detect a reconfig is done and can deallocate resources for the plugins
> registered at startup?
For each view, "rndc reconfig" is supposed to create and configure a new view,
move the zones from the old view to the new one, and then destroy the one.
The destroy function for the view should clean up plugins:
| if (view->plugins != NULL && view->plugins_free != NULL) {
| view->plugins_free(view->mctx, &view->plugins);
| }
view->plugins_free is a pointer to ns_plugins_free(), which calls
unload_plugin() for each plugin configured in the view, and that calls
the plugin_destroy() function defined in the module.
If you have the logging level set to debug(1), you should see "unloading
plugin" in your log file when this happens.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
when does bind calls plugin_destroy ?
Hi, I am developing a plugin for Bind. The API has 4 functions: plugin_register, plugin_check, plugin_version and plugin_destroy. In a test setup there are two instances of the same plugin and everything works as expected (plugin_register is called twice - once for each view). However, "rndc reconfig" calls plugin_register again twice but does not call plugin_destroy... This surprises me since the plugin has no knowledge of the reconfig and just initializes two more instances of the plugin without destroying the two that it created during startup. So, does anyone know when plugin_destroy is called and perhaps how a plugin can detect a reconfig is done and can deallocate resources for the plugins registered at startup? Thanks, Marcus -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
