Procedure: - Run `pkg install -y avahi-app` as root. - Add the following lines to /etc/rc.conf: ``` avahi_enable="YES" dbus_enable="YES" ``` - Run `service avahi-daemon restart` as root. Actual results: avahi-daemon terminates at startup with a message about not being able to connect to the dbus listening socket. Expected results: `avahi-daemon` should start its dependencies (in this case dbus) as needed, like many other services do. Other thoughts: Adding `force_depend dbus || return 1` to the precmd would be the right way to achieve what I described above using the existing rc.d framework.
(In reply to Enji Cooper from comment #0) > Actual results: > avahi-daemon terminates at startup with a message about not being able to connect to the dbus listening socket. I fail to reproduce this. Everything's working for me. > Adding `force_depend dbus || return 1` to the precmd would be the right way to achieve what I described above using the existing rc.d framework. How's so? Isn't "REQUIRE: dbus" enough?
(In reply to Gleb Popov from comment #1) > I fail to reproduce this. Everything's working for me. The problem occurs if dbus is not already running. I should have added that note to the repro :/. > How's so? Isn't "REQUIRE: dbus" enough? That handles the init(1) starting services at boot case. That doesn't handle the case where someone tries installing avahi-app without dbus first running, then trying to start avahi.
This is a generic "a service requires another service" problem. We should either do nothing about that or solve it in a generic way. There is nothing special about dbus and avahi. Both Bapt and me came to idea of enabling rc.d services automatically on a package install. It is not yet implemented and it is up to user whether to enable it. Having this feature disabled (like it is now effectively) means that the user is expected to enable services manually. (In reply to Enji Cooper from comment #2) > `avahi-daemon` should start its dependencies (in this case dbus) as needed, like many other services do. What services do this?
(In reply to Gleb Popov from comment #3) > Both Bapt and me came to idea of enabling rc.d services automatically on a package install. It is not yet implemented and it is up to user whether to enable it. Having this feature disabled (like it is now effectively) means that the user is expected to enable services manually. This seems like it would have undesirable security implications for sysadmins operating unattended package upgrades. > What other services do this? I thought net/samba did, but I guess not? We have other components in base that do, like NFS and NIS and there are a limited set of ports that do this as well: ``` % rg force_depend x11/cde/files/dtcms.in 21:start_precmd="force_depend rpcbind || exit 1" x11/cde/files/dtcms25.in 21:start_precmd="force_depend rpcbind || exit 1" x11/cde-devel/files/dtcms-devel.in 21:start_precmd="force_depend rpcbind || exit 1" x11/cde-devel/files/dtcms.in 21:start_precmd="force_depend rpcbind || exit 1" sysutils/am-utils/files/amd.in 24: force_depend nfsclient nfs_client || return 1 25: force_depend rpcbind || return 1 ```
(In reply to Enji Cooper from comment #4) I might also be accidentally conflating UX with other OSes like Fedora and Ubuntu Linux.. so much of this stuff tends to blend together after a while. So, this might ultimately be a feature request not unique to this port. If the new rc.d daemon bapt@ is working on resolves this more cleanly, that would be nice.
(In reply to Enji Cooper from comment #4) > This seems like it would have undesirable security implications for sysadmins operating unattended package upgrades. It is a matter of the chosen default for this feature, which I hope would be opt-in rather than enabled by default.