|Summary:||RFE: Support multiple names for BusName=|
|Product:||systemd||Reporter:||Elias Probst <mail>|
|Status:||NEW ---||QA Contact:||systemd-bugs|
|i915 platform:||i915 features:|
Description Elias Probst 2014-05-04 20:48:49 UTC
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.
Comment 1 Elias Probst 2014-05-04 21:09:41 UTC
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