Arch Linux

Tried to add 'RuntimeDirectory=connman' to the Unit portion of the service file and was unsuccessful.

Was able to hack it to create the directory by adding 'ExecStartPre=/bin/mkdir -p /run/connman' which is not
considered proper with systemd 245 but it does work and stays through a reboot...

That directive belongs into the [Service] section, I have it working in my override like this:

# /etc/systemd/system/connman.service.d/override.conf
[Service]
RuntimeDirectory=connman
ExecStart=
ExecStart=/usr/bin/connmand --wifi=iwd_agent --nodnsproxy -n


I'm not sure this is good to have in the default configuration, that would require symlinking the resolv.conf file to use connman.
It is mostly useful with a custom dns resolver and I have added that at the appropriate place in the wiki here:
https://wiki.archlinux.org/index.php/ConnMan#Avoiding_conflicts_with_local_DNS_server

Yes, this can/does work, but the true fix, I believe, is to make sure that the connman package creates this folder at install and I think it should be in the tmpfiles.d/ folder.

I noticed the PKGBUILD for connman explicitly deletes the ${pkgdir}/usr/lib/tmpfiles.d directory created by the build.

Otherwise, the package would contain this:
cat pkg/connman/usr/lib/tmpfiles.d/connman_resolvconf.conf
d /var/run/connman - - - -
L /etc/resolv.conf - - - - /var/run/connman/resolv.conf

Perhaps it was removed so connman wouldn't overwrite /etc/resolv.conf.
The fix should be to retain the tmpfiles.d file but just remove the line creating the /etc/resolv.conf link.
That way, users can manually link /etc/resolv.conf to /var/run/connman/resolv.conf or their preferred resolver.

Looking through this, again and I see that the tmpfiles.d file is created, but it uses the /var/run prefix as opposed to the Arch standard /run. Do I have this correct that this is an error or is it accepted to use /var/run interchangeable with /run? When I grep the /usr/lib/tmpfiles.d dir, the only config that uses /var/run is connman.

Yes, I believe it should be creating /run/connman instead of /var/run/connman.
But the current package doesn't install anything into /usr/lib/tmpfiles.d because of this change that was made way back in 2016:

https://github.com/archlinux/svntogit-community/commit/ee20ae8f03bd8ba9dfd779284a3d0f1cc8f5667f

Notice the removal of "$pkgdir"/usr/lib/tmpfiles.d in that change.

If that file is reinstated, I think it should look like:
d /run/connman - - - -
L! /etc/resolv.conf - - - - /run/connman/resolv.conf

I believe the ! after the L should avoid overwriting the symlink.

So, here are my suggested changes to build a package that includes a tmpfile as above (sorry, I don't know how to create a PR for this):

$ diff PKGBUILD.orig PKGBUILD
22c22,23
< 'allow_group_network.diff')
---
> 'allow_group_network.diff'
> 'connman_resolvconf.conf.diff')
25c26,27
< '06dd5867d460f1c3cf6c359e650ca2ef24495493a99cd03dbd17f23e587e9066d9bc98758d85d5c690d1ae21fa77ad8da5e2fa83d0b52c95d7a535784c5c4964')
---
> '06dd5867d460f1c3cf6c359e650ca2ef24495493a99cd03dbd17f23e587e9066d9bc98758d85d5c690d1ae21fa77ad8da5e2fa83d0b52c95d7a535784c5c4964'
> '17cab752aa7bf4e1a538580148943e48f8c2f4e304b6f9c05f7f664991909c69a20d8a3c7b52bcd93a9075a76b97cc91060b5fcb3e699701fdd74855897d5cd7')
30a33
> patch -Np1 -i "${srcdir}/connman_resolvconf.conf.diff"
36a40
> --runstatedir=/run \
60d63
< rm -r "${pkgdir}"/usr/lib/tmpfiles.d

-----------------------------------------------------------
$ cat connman_resolvconf.conf.diff
--- a/scripts/connman_resolvconf.conf.in.orig
+++ b/scripts/connman_resolvconf.conf.in
@@ -1,2 +1,2 @@
d @runstatedir@/connman - - - -
-L /etc/resolv.conf - - - - @runstatedir@/connman/resolv.conf
+L! /etc/resolv.conf - - - - @runstatedir@/connman/resolv.conf

 FS#67876 

No, L! only acts at boot time, L doesn't overwrite the symlink already.

I've been using this without problems:

d /run/connman - - - -
L /etc/resolv.conf - - - - /run/connman/resolv.conf

BTW. If you are going to show a patch with `diff`, it's better to use the unified format `diff -u`.

This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.