Missing link causes avahi to not be started on demand by systemd when needed about avahi

[michaellass]

I assume this has never really been solved, right? To me it seems that avahi's dbus activation is clearly broken. There are two cases to consider:

1. avahi-daemon.service has not been enabled via systemd. Then dbus activation via org.freedesktop.Avahi.service cannot work because that file says SystemdService=dbus-org.freedesktop.Avahi.service. However, the alias dbus-org.freedesktop.Avahi.service is not known to systemd because that symlink is only created when avahi-daemon.service is enabled.
2. avahi-daemon.service has been enabled via systemd. The dbus activation would work because the alias is known. However, it is basically unnecessary because avahi-daemon.service is anyway automatically started at boot up.

So, currently there is no way to have avahi-daemon.service only be started when requested via dbus.

[2023-09-09 16:11] Quick addition:
systemd uses a very similar pattern for several of its services (hostnamed, timedated, etc.). To make it work, they provide corresponding symlinks next to the service files:

bevan@zenpad ~ % ls -la /usr/lib/systemd/system/dbus*
-rw-r--r-- 1 root root 410  2. Sep 15:42 /usr/lib/systemd/system/dbus.service
-rw-r--r-- 1 root root 102  2. Sep 15:42 /usr/lib/systemd/system/dbus.socket
lrwxrwxrwx 1 root root  25  7. Sep 09:47 /usr/lib/systemd/system/dbus-org.freedesktop.hostname1.service -> systemd-hostnamed.service
lrwxrwxrwx 1 root root  23  7. Sep 09:47 /usr/lib/systemd/system/dbus-org.freedesktop.import1.service -> systemd-importd.service
lrwxrwxrwx 1 root root  23  7. Sep 09:47 /usr/lib/systemd/system/dbus-org.freedesktop.locale1.service -> systemd-localed.service
lrwxrwxrwx 1 root root  22  7. Sep 09:47 /usr/lib/systemd/system/dbus-org.freedesktop.login1.service -> systemd-logind.service
lrwxrwxrwx 1 root root  24  7. Sep 09:47 /usr/lib/systemd/system/dbus-org.freedesktop.machine1.service -> systemd-machined.service
lrwxrwxrwx 1 root root  25  7. Sep 09:47 /usr/lib/systemd/system/dbus-org.freedesktop.portable1.service -> systemd-portabled.service
lrwxrwxrwx 1 root root  25  7. Sep 09:47 /usr/lib/systemd/system/dbus-org.freedesktop.timedate1.service -> systemd-timedated.service

This is just missing for avahi.

[lathiat]

According to the following URL:
https://fedoraproject.org/wiki/Packaging:Systemd#DBus_activation

Note that the creation/removal of the alias symlinks should be done with "systemctl enable" and "systemctl disable" only. You should not create these symlinks manually

From reading that I would suggest the "proper" fix is to run systemctl enable during post-install to install the symlink. Thoughts?

Looking at the fedora spec, it seems to do this when upgrading from pre-systemd:
/usr/bin/systemctl --no-reload enable avahi-daemon.service >/dev/null 2>&1 || :
/usr/bin/systemctl try-restart avahi-daemon.service >/dev/null 2>&1 || :

During non upgrades seems they use some rpm mechanism to basically do the same:
%systemd_postun_with_restart avahi-daemon.socket avahi-daemon.service

So I feel like I'm generally correct.. the exact syntax probably depends on the package manager and the 'standard' way of handling this during installation

[pacho2]

Well, the problem is how to ensure make install will provide the link as, otherwise, people will simply see in the logs that the service is failing to start because of "No such file or directory" :/

Or maybe it could show a warning at the end (I bit like it's done in some packages for remembering people to run update-mime-database and similar)

[pacho2]

I have sent a mail to systemd list, hopefully they will know :)
http://lists.freedesktop.org/archives/systemd-devel/2015-October/034736.html

[lathiat]

OK based on the reply you got, the service file that Fedora ships is the same one we ship.. that info is there.

That info is used and actioned by "systemctl enable avahi-daemon", by default it's disabled. I'm fairly sure that is what should be done by "make install" and your distro-specific post-install script should run "systemctl enable" - which is basically the better equivalent to your manual symlink.

I don't think "make install" should run systemctl enable.

[pacho2]

Per the following comments in the mailing list, it seems that we should go with the Fedora way of doing it... even if it seems people will need to still manually enable avahi :/

[lathiat]

I'm confused as to why your distribution script cannot run this command, to 'automate' the process (nothing manual required). I don't think it makes sense to automate this in "make install" but it makes perfect sense during package installation (depending of course, on the policy if your distribution.. Debian seems to almost always auto-start things, fedora is a bit more so-so about that).

[pacho2]

Well, in our case (Gentoo) we support at least two init systems (systemd and openrc), then, we cannot enable it blindly. Even for setups running systemd, we don't think it's ok to automatically enable a service a user would not be aware of. What it's a non sense to me is that, if we don't enable the service to get it running all the time, people will simply get a "no such file or directory" failure when systemd tries to spawn avahi but it cannot do that because of the link being missing :/

[lathiat]

OK I think I understand your concern now.. the issue is that basically you cannot do "start" without first doing "enable", am I right?

[pacho2]

It looks like systemd cannot start it automatically without the link... it's like a nonsense to me :/

Using the link is "bad" because... some kind if policy, but systemd tries to use that link to start it when needed

On the other hand, they force people to "enable" the service (and, then, having it enabled always) to get it started :|

[evverx]

it is basically unnecessary because avahi-daemon.service is anyway automatically started at boot up

It can go down for whatever reason in the process and if it is enabled it can be started again via D-Bus so clients using D-Bus API can somewhat fix transient issues.

systemd uses a very similar pattern for several of its services

It doesn't use it for services receiving network packets like resolved, networkd and timesyncd and avahi falls into that category. If it isn't enabled explicitly it's unlikely that the firewall and the network interfaces are set up either.

I think it can be closed.