Arch Linux

Removing /usr/lib/tmpfiles.d/connman_resolvconf.conf results in a broken resolv.conf with connman 1.31-2 on my system. Instead of getting a resolv.conf generated by connman I have a broken leftover symlink to /var/run/connman/resolv.conf (probably from connman 1.31-1).

Overwriting resolv.conf with a dynamically generated resolv.conf is standard behavior for networking processes like Connman and NetworkManager (i.e. it's not a bug). Connman has always done this. For further info, look at: https://wiki.archlinux.org/index.php/Resolv.conf#Preserve_DNS_settings

While connman 1.31 should fall back to directly overwriting /etc/resolv.conf if /var/run/connman isn't present, it fails to do so on my system. I've tried to removing the resolv.conf symlink and replacing it with an empty resolv.conf but so far I haven't been able to make this work. I suspect there might be an upstream bug in the fallback code involved.

Re-enabling /usr/lib/tmpfiles.d/connman_resolvconf.conf fixes the problem for me. My suspection is that the problem the original reporter of this bug encountered is related to a problem with systemd-tmpfiles-setup.service on his system.

Please note that DNS is actually working on my system despite the broken resolv.conf. Only some processes like docker which rely on a correct resolv.conf are failing.

I did some more digging around and it seems the failure of the fallback mode is probably caused by a change in the connman.service file provided by connman. In connman 1.31 the line

ProtectSystem=full

was added which effectively protects /etc from writes by connman. So we could either

1) keep removing the tmpfile and patch connman.service to use less restrictive protection (ProtectSystem=true allows for writes to /etc)
2) use the tmpfile

I haven't tested this yet but the first approach probably would have the benefit of restoring /etc/resolv.conf after connman exits while keeping the tmpfile would make the symlink permanent even if we're not using connman. However, the resolv.conf page on the Archlinux wiki suggests NetworkManager does the same. Both solutions would be OK for me but I'm not sure which one is preferable.

NetworkManager overwrites the file, it doesn't create a symlink. Replacing a file owned by a package (such as resolv.conf) with a symlink is calling for trouble, it will cause issues with future updates of the package.

Yes, I agree. This is was gave me these troubles in the first place.

You can add this line to the package() function in the PKGBUILD to fix the connman service file:

sed -i s/ProtectSystem=full/ProtectSystem=true/ "$pkgdir"/usr/lib/systemd/system/connman.service

I've tested this after removing the symlink and the /var/run/connman directory and it works fine. The only question remaining is what to do about the leftover symlink from 1.31-1. Ask the users to remove it manually?

I'm using connman 1.31-2. It seems that i missed the 1.31-1 and therefore had no /var/run/connman directory. Although i had a symlink /etc/resolv.conf pointing to missing /var/run/connman/resolv.conf.

I set ProtectSystem=full in service file, restarted the connman and now the /etc/resolv.conf has correct contents (nameserver is 127.0.0.1, as expected).

Thanks Felix!

Please test 1.31-3

Works fine here, thank you!

was OK in -2, but overwrites the file again in -3...

$ ls -la /etc/resolv.conf
lrwxrwxrwx 1 root root 28 мар 12 22:18 /etc/resolv.conf -> /var/run/connman/resolv.conf

$ ls -la /var/run/connman/resolv.conf
-rw-r--r-- 1 root root 70 мар 14 20:53 /var/run/connman/resolv.conf

$ cat /var/run/connman/resolv.conf
# Generated by Connection Manager
nameserver 127.0.0.1
nameserver ::1

All as expected...

Sure, but replace that /etc/resolv.conf with your own config and reinstall - your config file will disappear.

This is expected behavior for any network manager. See https://wiki.archlinux.org/index.php/Connman#Avoiding_conflicts_with_local_DNS_server

Just to clarify this, the fix proposed in my last comment is intended to fix connmans fallback mode (which is connman using /etc/resolv.conf directly whenever /var/run/connman isn't available) when using systemd and not installing the tempfiles file shipped with connman. This is needed in this case because the systemd unit shipped with connman has a setting that write-protects /etc from connman (other processes will be fine) so the fallback mode code can't write to /etc/resolv.conf as it did it in the previous connman releases. When using the tempfiles, connman will not invoke the fallback code and use /var/run/connman/resolv.conf, so the fix isn't needed in this case.

As for the question whether or not the symlink from /var/run/connman/resolv.conf to /etc/resolv.conf should be set by the tempfile I don't have an answer. Technically this is only provided for compatibility reasons and most programs will use the DNS proxy provided by connman anyways. So my proposal to handle this would be to remove the creation of this symlink from the tempfile shipped with connman and let users decide whether they want to set up the symlink for compatibilty. Systemd-networkd also keeps it's own copy of resolv.conf in tmpfs and setting the symlink to /etc/resolv.conf is optional.

Also just to clarify in case this has wandered too far from the original report - this looks like a packaging issue, and nothing to do with it being a "network manager" and conflicting port bindings.
This could be a text editor or anything, it shouldn't overwrite config files.

Every other package does this https://wiki.archlinux.org/index.php/Pacman/Pacnew_and_Pacsave#Package_backup_files

"Every other package does this" - No, they don't. This has nothing to do with backup files. Backup files are created by pacman when a configuration file belonging to a package is modified and the package is reinstalled. Not when applications modify configuration files at runtime.

And of course it has to do with being a network manager, NetworkManager and netctl also modify the file (via openresolv).

It's not running though, so as far as I'm aware, there is no "runtime".

Installed or reinstalled - this changed in pacman 5, and used to be .pacorig but has since been changed to match the reinstall behaviour (new file is .pacnew)

1.31-5 shouldn't create the symlink anymore, and overwrite resolv.conf instead.