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: - org.kde.kuiserver - org.kde.JobViewServer 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
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.