[systemd-devel] Questions regarding dbus started via systemd --user

[Simon McVittie]

Adding D-Bus mailing list to Cc; questions about the user bus are
significant for D-Bus as well as for systemd --user, and modifications
of dbus-launch doubly so.

On 08/01/15 11:55, Colin Guthrie wrote:
> I've got a modified dbus-launch that can be slotted in nicely

I'm happy for dbus to get better integration with systemd --user (and I
plan to work on it myself at some point) but I would much prefer
dbus-launch to not be the way it happens.

Modifying dbus-launch is fine for experimentation, but I would really
like it to become a historical curiosity for people with bizarre
multi-machine X11. It's fairly horrible code and there has never really
been a canonical list of what is and isn't intended to work. Instead of
altering dbus-launch, I would very much prefer to give
libdbus/GDBus/etc. a better thing they can try before calling
dbus-launch; I believe the current suggestion is looking for a Unix
socket in XDG_RUNTIME_DIR/bus (formerly
XDG_RUNTIME_DIR/dbus/user_bus_socket like in user-session-units).

In particular, on Wayland systems, I would like dbus-launch to be
something that is not relevant and never has been.

Related:

https://bugs.freedesktop.org/show_bug.cgi?id=61301
https://bugs.freedesktop.org/show_bug.cgi?id=61303
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681241
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774626

> It also pokes systemd --user with the environment
> too.

I attach a prototype of a standalone dbus-update-activation-environment
tool, left over from last time I looked into this. It pokes all of its
environment variables into both dbus-daemon (required) and "systemd
--user" (if present), then execs its arguments. It is untested, and
should probably upload variables specified by command-line arguments
rather than all of them, and exit 0 rather than exec'ing an argument;
but it's a start.

I think having the X session or PAM stack do something similar to that
is likely to be a better approach to compatibility with code that
assumes environment variables propagate through the whole session (e.g.
Debian's Xsession.d) than having dbus-launch grow yet more magic.

The observant will notice that I have not attached it to a feature
request or anything; that's because it probably doesn't work yet, I got
halfway through prototyping it.

> The issue I currently have is that the dbus daemon itself is now part of
> the user at .service cgroup and NOT part of the session cgroup

I think that's unavoidable; if we want any services that exist outside
the scope of an individual login session, then this is how they are
going to have to work.

> In GNOME for example, gnome-terminal is started via dbus activation
> (gnome-terminal-server).

I think that's OK. Anything "in the foreground" whose lifetime is tied
to the shell will die from SIGHUP when gnome-terminal exits because the
terminal got disconnected from X11. Meanwhile, anything that has done
the usual shell things to go to the background, or is in a screen or
tmux, ends up in the same situation as a D-Bus session service or a
systemd user service: it survives for exactly as long as systemd --user
(which might persist after last-logout, or not, according to sysadmin
configuration) and then dies. Either way, it seems like what you want?

As I understand it, the supported situations are "systemd --user lasts
longer than the X11 session" (for normal use) and "systemd --user lasts
exactly as long as the X11 session" (for shared computers where the
sysadmin wants to avoid non-session processes hanging around), but not
"systemd --user exits before the X11 session does".

    S
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debian-dbus-update-activation-environment.c
Type: text/x-csrc
Size: 5186 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20150108/dcef5018/attachment.c>