Having a service dbus activated which provides more than 1 bus name is currently not possible (without workarounds), as BusName= is interpreted as literal string and not as a list of bus names.
e.g. I have the user-session service 'kuiserver' which exposes 2 bus names:
As there's no way to make sure all applications will only use one of the 2 bus names, systemd needs to "listen" on both of them to be able to dbus activate 'kuiserver.service'.
A current workaround is, to have separate socket services which point to the actual service, but that's not really straightforward.
Based on my experience, there are actually quite a lot applications having more than 1 bus name, so this wouldn't be just a corner case to be solved here.
A bit of IRC log discussing this issue + a workaround for now:
[22:49:01] <eliasp> falconindy: k, bug filed: https://bugs.freedesktop.org/show_bug.cgi?id=78265
[22:49:47] <falconindy> does having multiple .busname units work, though?
[22:52:53] <eliasp> meant .busname in the report, not .socket… but now actually looking at it… can't find anything regarding .busname units…
[22:53:16] <falconindy> they aren't documented =/
[22:53:24] <falconindy> they might only work with kdbus
[22:53:37] <eliasp> falconindy: ah, k… so no really usable workaround right now
[22:54:07] <falconindy> perhaps that's the case
[22:54:37] <eliasp> me, shit… hmm… defining a 2nd service with the 2nd busname, no ExecStart in it… would that work? /me goes to read + try
[22:54:41] <falconindy> ah yeah... NEWS file mentions busname units only for kdbus
[22:54:52] <eliasp> falconindy: hmm, k… ;(
[22:55:02] <brain0> busname is an equivalent for the dbus-1 .service files
[22:55:03] <falconindy> well, both BusName units would have the same Unit=
[22:55:10] <brain0> for kdbus
[22:55:33] <brain0> on non-kdbus, it makes no sense to have such a unit
[22:55:50] <falconindy> right, because systemd can't be the proxy
[22:56:40] <eliasp> ah, so as long as there's no kdbus, enabling a service via D-Bus isn't possible at all?
[22:56:52] <eliasp> s/enabling/starting/g
[22:57:15] <brain0> it is
[22:57:19] <falconindy> it is possible -- it just depends on the system dbus daemon
[22:57:21] <brain0> with a dbus-1 .service file
[22:57:39] <brain0> you can also do it on the user bus
[22:57:56] <brain0> but that only works if the systemd user instance and dbus user bus integrate well
[22:58:04] <brain0> which right now, no desktop will do
[22:58:14] <brain0> but it is possible
[22:58:38] -*- thestinger would use --enable-kdbus if it didn't break networkmanager :P
[22:58:42] <eliasp> brain0: well, that's what I'm working at… my setup doesn't do a dbus-autolaunch anymore and exports DBUS_SESSION_BUS_ADDRESS to point to the user-session launched dbus
[22:58:49] <brain0> basically, the systemd user instance has to know the display and other environment variables, and all dbus user services must have a SystemdUnit= statement
[22:59:03] <thestinger> or maybe it's wpa_supplicant it breaks, same end result
[22:59:13] <eliasp> brain0: except of SystemdUnit= … that's all solved here
[23:00:28] <eliasp> brain0: can't find any documentation on SystemdUnit= … any pointers?
[23:01:13] <brain0> cat /usr/share/dbus-1/system-services/org.bluez.service
[23:01:25] <brain0> basically, you add the name of a systemd unit that it activates
[23:02:27] <eliasp> hmm, bluez-5.18 here (so up-to-date) but this unit has only SystemdService=dbus-org.bluez.service … that's what you meant, right?
[23:03:59] <brain0> yes
[23:04:20] <brain0> this basically means: if org.bluez is requested, activate dbus-org.bluez.service
[23:04:43] <brain0> in this case, the Exec= and User= arguments in that file are ignored
[23:04:56] <brain0> they are only there for running dbus without systemd
[23:08:10] <eliasp> brain0: ok, great… this should solve that problem for now