Am 02/05/2016 um 06:26 PM schrieb Giacomo Mulas: > On Fri, 5 Feb 2016, Michael Biebl wrote: > >> Ok, thanks for testing. >> Do you use openresolv or resolvconf? > > openresolv. > >> Afaics that hook is only relevant, if the interface is managed by >> ifupdown. > > No. I just added a line > > echo "resolvonfhookcalled" >/home/gmulas/openresolvtest
Well, as I wrote, the scripts are indeed called by NetworkManager (via /etc/NetworkManager/dispatcher.d/01ifupdown), *but* the IF_DNS_* variables are not set if the interface is managed by NM, so, the hook scripts becomes basically a nop. You could just try to move it away (temporarily) and see what happens when you activate/deactivate a NM managed interface. > in /etc/network/if-up.d/000resolvconf, took down the wifi interface managed > by Network Manager via Network Manager (i.e. via the gnome control panel > which uses Network Manager), took it up again and, lo and behold, I found > the previously nonexistent /home/gmulas/openresolvtest file which contained > the string "resolvonfhookcalled"... So yes, the hooks in > etc/network/if-up.d, if-pre-up.d, if-down.d and > /if-post-down.d do get called when interfaces are > configured/deconfigured by > Network Manager. Therefore, Network Manager should take it into account > when > configuring/deconfiguring interfaces and avoid duplicating what is done > already by those hooks. I think it already does. As said, NM will only push the dns information to /sbin/resolvconf but no longer touch /etc/resolv.conf directly. >>> By the way, is it Network-Manager or resolvconf that tries to restart >>> named.service and unbound.service? >> >> That seems to be resolvconf which tries to restart those services. >> See the scripts in /lib/resolvconf/. Looks like a bug if tries to >> restart non-exising service > > as long as it's harmless, who cares. >> I believe it's /sbin/resolvconf directly which does it via the hooks in >> /lib/resolvconf. > > As I told you above, I did check that the hooks in /etc/network/if-*.d > directories do get executed, so now I'm pretty sure that's what happens. They are. Have you seen my followup reply, btw? >>> So, finally, apparently openresolv already does the right things >>> whenever an >>> interface is brought up or down, so NetworkManager should just leave it >>> alone and all should work? >> >> What NetworkManager does, if /sbin/resolvconf is installed, is to push >> the DNS information to the resolvconf binary and nothing else. > > well, apparently either resolvconf does not work properly or NetworkManager > does not call it as it expects to be called, since it fails (from the debug > output of NetworkManager): > > NetworkManager[26333]: <warn> dns-mgr: resolvconf failed with status 3072 > NetworkManager[26333]: <debug> [1454681100.577095] > [dns-manager/nm-dns-manager.c:549] update_resolv_conf(): dns-mgr: not > updating /var/run/NetworkManager/resolv.conf since it points to > /etc/resolv.conf This one is expected, since NM won't touch /etc/resolv.conf if resolvconf is installed. > NetworkManager[26333]: <warn> dns-mgr: could not commit DNS changes: > resolvconf failed with status 3072 This one is the interesting error case. Does the openresolvconf man page document, what return code 3072 means? I suspect there might be incompatibilities between openresolv and resolvconf. Could you try installing resolvconf instead of openresolv and see if that exhibits the same problem? > In any case, this appears to be harmless, since the interface is activated > and resolvconf does its job via the hooks. I don't think the hooks are respsonsible for updating /etc/resolv.conf (see above). But it would still be interesting to know, why /sbin/resolvconf returns a non-zero exit status. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature