[Pkg-utopia-maintainers] Bug#813803: Bug#813803: Bug#813803: network-manager: Network-manager update to 1.1.90-4 in unstable broken if resolvconf enabled

[Michael Biebl]

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-utopia-maintainers/attachments/20160205/b18a8a85/attachment-0001.sig>