mirror of
https://github.com/isc-projects/bind9.git
synced 2026-05-25 02:47:54 -04:00
d7dbfbb011
When a re-configuration fails, `apply_configuration` flows jump to a cleanup label and, at some point, leave the exclusive mode and cleanup the viewlist. It looks fine as the viewlist is at this point only locally known (if this is a configuration failure, this is the new view list, if this is a success, this is the old list which has been swapped out from the production list during the exclusive mode). However, the view and zone initialization code enqueues job callbacks, for instance from `dns_zone_setsigninginterval` (but there are others cases) which will be called for the new views and zones after the exclusive mode is over. Depending where the configuration fails, those views and zones can be half-configured, for instance a view might have an unfrozen resolver. Hence, leaving the exclusive mode before cleaning up those views ans zones will immediately called the previously enqueued callbacks and lead to this reconfiguration-failure crash stack: ``` isc_assertion_failed dns_resolver_createfetch do_keyfetch isc__async_cb ... uv_run loop_thread thread_body thread_run start_thread ... ``` To avoid the problem, the views are now cleaned up before leaving the exclusive mode (which also clean up the zones and enqueued callbacks). As context, the bug was introduced by !10910 which moved the creation (not configuration) of the view outsides of the exclusive mode. This is a safe move (as at this point, the newly view are only known locally by `apply_configuration`) but the re-order was wrong regarding the point where the exclusive mode was ended (before the change, the exclusive mode as always ended before the new view are detached). |
||
|---|---|---|
| .. | ||
| check | ||
| confgen | ||
| delv | ||
| dig | ||
| dnssec | ||
| named | ||
| nsupdate | ||
| plugins | ||
| rndc | ||
| tests | ||
| tools | ||
| meson.build | ||