| Summary: | RFE: Support multiple names for BusName= | ||
|---|---|---|---|
| Product: | systemd | Reporter: | Elias Probst <mail> |
| Component: | general | Assignee: | systemd-bugs |
| Status: | NEW --- | QA Contact: | systemd-bugs |
| Severity: | normal | ||
| Priority: | medium | CC: | egorov_egor, rektide |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Elias Probst
2014-05-04 20:48:49 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 |
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.