[systemd-devel] Systemd --user and the role of DBUS API

[Mantas Mikulėnas]

On Wed, Aug 19, 2015 at 4:47 PM, Ian Geiser <igeiser at devonit.com> wrote:

> On Wed, Aug 19, 2015 at 2:55 PM, Ian Geiser <igeiser at devonit.com> wrote:
> > Greetings, I am struggling with search queries here so I need to ask
> this outright.  "what is the role of dbus going forward?"  Is dbus the
> preferred way going forward?  Or should things really be using sd-bus.h
> instead?
>
>
>
> D-Bus is not going away, only its internals are being replaced. Existing
> clients will continue working.
>
>
>
> kdbus replaces the "dbus-daemon" router and the Unix socket transport with
> a direct kernel API, but all existing programs can still connect to it via
> systemd-bus-proxy (at least until they get native kdbus support).
>
>
>
> sd-bus.h is only a library for writing DBus clients & servers. Here the
> choice is still up to you – sd-bus has better performance and native kdbus
> support (and a better API than e.g. dbus-glib), but if you're writing
> programs in GTK or Qt or EFL, then you'll still want GDBus or QtDBus or
> Eldbus.
>
>
>
> *[igeiser] *Awesome, thanks for the clarification
>
>
>
> (I've heard GDBus already has native kdbus support in development, too.)
>
>
> > I manage an embedded product that leverages system heavily at the system
> level, but I want to expand this into the user session. The main focus is
> to use "scopes" for classification and control of specific application's
> process groups.  The rub here is that while system-run can do this if I try
> to do this via dbus the org.freedesktop.systemd1 is missing from the user
> session no matter what or where I set my DBUS_SESSION_BUS_ADDRESS.  I am
> using systemd  224.
>
> Right, systemd will not be accessible on a session bus, since it runs
> *outside* the session.
>
>
>
> So instead you'll find it on the *user* bus, which is available by
> default on kdbus systems, but can be configured with dbus-daemon as well.
> The current devel branch (1.9.20) of dbus-daemon installs the --user units
> dbus.socket and dbus.service necessary for this. The user bus address is
> "kernel:path=/dev/kdbus/$UID-user/bus;unix:runtime=yes" (if I got the
> syntax right?), or
> "kernel:path=/dev/kdbus/$UID-user/bus;unix:path=/run/user/$UID/bus".
>
> *[igeiser] *Can I access it using the path directly in 1.8.x using
> ”unix:path=/run/user/$UID/system/private”? Or is that what the 1.9.20
> allows to happen?
>

Not quite; …/systemd/private is not even a bus – it's a direct peer-to-peer
connection to systemd, providing just that one service. (It is therefore
independent of which dbus-daemon version you're running.)

So you need to connect to it in a slightly different way
(e.g. "g_dbus_connection_new_for_address()").

Also keep in mind that this socket is for internal systemd use only (hence
its name), and can be removed from systemd *at any time *in some future
release. For your own projects it's better to set up the actual user bus.


> (Technically the same can be done with dbus 1.8.x as well, but AFAIK the
> developers do not approve.)
>
>
>
> *[igeiser] *Is this the method various “user units” howtos add a
> dbus.socket and dbus.service into the user directory?  I will research the
> dbus repo for their details.  This is happy lab fun time so I am play with
> hacks if they don’t lead me away from the official solution.
>

Yes, that would work. (Though e.g. if you use polkit it should be the very
latest version as well.)

[Also that's some *weird* quoting style of yours]

-- 
Mantas Mikulėnas <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150819/5f7fcf1c/attachment-0001.html>