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

[Colin Guthrie]

Hi Simon,

Hope my reply gets through to both lists (can't remember if I sub'ed to
dbus in the past - I always read via gmane but am allowed to post on
most of the lists...)

Simon McVittie wrote on 08/01/15 12:39:
> 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.

No worries and indeed. I was more asking about the consequences from the
end result with the cgroups etc, but it is indeed relevent to dbus folks
too so I should have through to cross post originally.

> 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.

Oh indeed. I look forward to the day when dbus-launch is gone!

> Modifying dbus-launch is fine for experimentation, 

Yeah this is mainly just an early stage PoC to study the effects of
things without necessarily unpicking all the various plumbing (mostly
consisting of sticky tape, glue and good will) that most of the
different X11 sessions are launched using.

> 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.

Yeah that's mostly what happens in my patch.

Here it is FWIW: http://pastebin.com/raw.php?i=jLvRpyhF

I've not used libdbus1 before so the coding style likely leaves a lot to
be desired!

It's definitely not finalised and as I said it's more PoC than something
that would be a real solution (although I wouldn't rule it out being
used in a distro during the transition period, but certainly it
shouldn't be a long term thing.

> 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

Thanks!

>> 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.

Oh this is very similar to what I hacked into dbus-launch. I knew
someone would have done this already so should have looked harder for
examples. Very much the same concept tho'.

> 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.

Yup I agree in principle. Although when I discussed this on the ML
before, one case which a PAM solution wouldn't address is people running
"startx" after logging into a tty session (corner case I know but
whenever I break that, I get people shouting at me so I'd rather avoid
that :D)

So although from a cleanliness I think it's the right place, I'd say it
would have to be in the X session. I've not really looked at what that
would entail.

> 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.

Well, if it's any consolation, I'm running a pretty full gnome setup
just now with my version and it seems to work OK.

The only issue is various processes being in the "wrong" cgroup, but
it's not too bad really.

>> 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.

Yeah.

>> 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".

Yup, it feels like it's all working OK, but we'll see when I unleash it
on a wider test bed :)

Thanks for your other reply too. I concur on what you said and my
"obviously" statement is indeed not wholly true in some circumstances as
you said. It sometimes is and sometimes isn't as you outlined! :)

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/