On Thu, 24 Nov 2016 at 17:35:58 +0100, Michael Biebl wrote:
> See for example dbus-user-session, which ships
>
> /usr/lib/systemd/user/dbus.service
> /usr/lib/systemd/user/dbus.socket
> and
> /usr/lib/systemd/user/sockets.target.wants/dbus.socket
Note that dbus is special: it is statically enabled by upstream, in
consultation with systemd upstream, because systemd --user itself benefits
from having access to a dbus-daemon. This is not the case for ordinary
user-services like pulseaudio, gnupg, gnome-settings-daemon and similar,
so should not necessarily be taken as precedent.
"Statically enabled" is jargon for units that do not have an [Install]
section, just a "hard-coded" symlink in /usr or /lib. They can't be
disabled, but they can still be masked, assuming you are willing to keep
both pieces if the system breaks as a result.
Similarly, the system dbus-daemon is statically enabled on the system bus,
unlike most "normal" system services, because systemd-as-pid-1 wants to
use it for systemctl and polkit (when installed).
It might be a reasonable middle ground for sockets and other
auto-activation mechanisms to be statically enabled on the user bus, so
that the services are not started eagerly, but are started on-demand?
Many systemd user services are D-Bus-activatable, and D-Bus .service files
are like having a statically enabled .socket unit (or more precisely,
a statically enabled .busname unit, in the alternate reality where
kdbus happened) - they do not have a concept of disabled state, but are
always willing to launch the referenced D-Bus service, either directly or
via systemd, when it is contacted.
smcv
