Replying to an old bugreport which is marked as fixed since 1.5.9-2 version.
This is, in fact, a context of resolvconf, for which we have several other bugreports. This one has a lenghtly discussion and debugging. But I can't understand the main thing there: why on the Earth one needs to reload postfix (or other similar software) due to changes of DNS forwarders, provided there's a caching nameserver running on 127.0.0.1? In this case, all local programs just use the default 127.0.0.1 as nameserver and need no reload whatsoever, /etc/resolv.conf does not change (well, unless a search path is also changing), all the complexity is handled by the caching nameserver internally, without clients even disconnecting. Is it not the case? Having said that, I'm aware of /etc/resolvconf/update.d/unbound being disabled for quite some time (#1003135). Maybe that's the whole reason of all this long debugging in this bug report, and the only thing actually needed was to enable this resolvconf integration? This whole unbound-resolvconf.service seems to be quite messy and it is unclear to me how it works to begin with. There are several pieces of this puzzle. Now we also have #1009928 which needs to be fixed but I don't understand the machinery behind this unbound-resolvconf.service. Also, lintian gives warnings about this: W: unbound: systemd-service-file-refers-to-unusual-wantedby-target unbound.service [lib/systemd/system/unbound-resolvconf.service] I: unbound: package-supports-alternative-init-but-no-init.d-script lib/systemd/system/unbound-resolvconf.service I: unbound: systemd-service-file-missing-documentation-key [lib/systemd/system/unbound-resolvconf.service] The first one is just that: it is _unusual_ to be wanted by anything but multi-user.target or the like. Robert, can you please give some summary of that's going on there if you still remember the context? I'm trying to understand the context provided in this bugreport (which lead to the current unbound-resolvconf.service) but it is a bit difficult to follow. Thank you! /mjt
