Discussion:
Questions regarding dbus started via systemd --user
(too old to reply)
Colin Guthrie
2015-01-08 11:55:30 UTC
Permalink
Hi,

I'm just playing around with this and making some progress.

I've got a modified dbus-launch that can be slotted in nicely to poke
dbus activated via systemd and teach it about the environment for
subsequent launching. It also pokes systemd --user with the environment
too. It's pretty simply and allows for experimentation without too much
impact.

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

i.e. here it is:

4:devices:/user.slice,1:name=systemd:/user.slice/user-603.slice/***@603.service/dbus.service

rather than in say:

4:devices:/user.slice,1:name=systemd:/user.slice/user-603.slice/session-c2.scope

I guess my question is: Is this OK?

It does have repercussions.

In GNOME for example, gnome-terminal is started via dbus activation
(gnome-terminal-server). This means all processes started inside
gnome-terminal actually are part of
4:devices:/user.slice,1:name=systemd:/user.slice/user-603.slice/***@603.service/dbus.service
cgroup.

I "solved" this by adding a user unit for gnome-termnial-server and
making dbus use systemd activation for it, but that just moves it to a
different cgroup. I guess it's OK like this.

One of the practical repercussions of this was that polkit auth from
gnome-terminal didn't work as the pids are not part of the same session.
This was fixed when I applied Kay's
http://cgit.freedesktop.org/polkit/commit/?id=a68f5dfd7662767b7b9822090b70bc5bd145c50c
to polkit.

But from now on things seem OK.

Is there any problems that people can think of of running such a setup
now without any further compartmentalisation or changes?

Col
--
Colin Guthrie
colin(at)mageia.org
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/
Simon McVittie
2015-01-08 12:39:34 UTC
Permalink
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.
Post by Colin Guthrie
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
Post by Colin Guthrie
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.
Post by Colin Guthrie
The issue I currently have is that the dbus daemon itself is now part of
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.
Post by Colin Guthrie
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
Colin Guthrie
2015-01-08 17:04:59 UTC
Permalink
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...)
Post by 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.
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.
Post by Simon McVittie
Post by Colin Guthrie
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!
Post by Simon McVittie
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.
Post by Simon McVittie
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.
Post by Simon McVittie
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!
Post by Simon McVittie
Post by Colin Guthrie
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'.
Post by Simon McVittie
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.
Post by Simon McVittie
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.
Post by Simon McVittie
Post by Colin Guthrie
The issue I currently have is that the dbus daemon itself is now part of
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.
Post by Simon McVittie
Post by Colin Guthrie
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/
Simon McVittie
2015-01-08 19:01:14 UTC
Permalink
Post by Colin Guthrie
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
I personally am very tempted to say that startx users get to keep both
pieces, and that the *dm family of services are just a better approach
all round...
Post by Colin Guthrie
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.
... but from a purely practical point of view, backwards compatibility
with assorted distributions' shell script X-startup glue (in Debian and
derivatives it's /etc/Xsession.d/*, in Red Hat derivatives I think
there's some long name featuring xinit that is basically the same idea?)
probably dictates that we need this, at which point startx benefits equally.

For what it's worth, the reason my previously attached hack was named
debian-dbus-* is that I had vaguely intended it to evolve into a
solution to "misc things in Debian expect to be able to set environment
variables in Xsession.d and have them propagate". If it's sufficiently
useful that I end up distributing something like it with my D-Bus
upstream hat on, great; but even if it only solves Debian-specific
problems, I still need it for my Debian Developer hat.

S
Lennart Poettering
2015-02-02 23:07:56 UTC
Permalink
Post by Simon McVittie
Post by Colin Guthrie
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
I personally am very tempted to say that startx users get to keep both
pieces, and that the *dm family of services are just a better approach
all round...
startx could simply invoke "systemctl import DISPLAY" after setting
it, and things should just work for it too, as long as it just takes
over the tty it is running on instead of allocating a new one.

Lennart
--
Lennart Poettering, Red Hat
Lennart Poettering
2015-01-08 13:19:53 UTC
Permalink
Post by Colin Guthrie
Hi,
I'm just playing around with this and making some progress.
I've got a modified dbus-launch that can be slotted in nicely to poke
dbus activated via systemd and teach it about the environment for
subsequent launching. It also pokes systemd --user with the environment
too. It's pretty simply and allows for experimentation without too much
impact.
The issue I currently have is that the dbus daemon itself is now part of
4:devices:/user.slice,1:name=systemd:/user.slice/user-603.slice/session-c2.scope
I guess my question is: Is this OK?
Yes, the idea is that these services become singleton services of the
user, and the sessions ultimately only retain a "stub" process that
does little more than maybe invoke something via systemd and hang
around until log out.
Post by Colin Guthrie
It does have repercussions.
In GNOME for example, gnome-terminal is started via dbus activation
(gnome-terminal-server). This means all processes started inside
gnome-terminal actually are part of
cgroup.
Yeah, non-converted bus services will appear as part of
dbus.service. That is ugly of course.

I kinda stopped pushing the per-user stuff until kdbus is done,
because this all resolves itself then, because bus services are then
converted into native systemd services.
Post by Colin Guthrie
Is there any problems that people can think of of running such a setup
now without any further compartmentalisation or changes?
Well, it's little tested, and I wish this would just work out of the
box. But again, I am kinda waiting for kdbus to finally be a done deal
before revisiting and pushing for this again...

Lennart
--
Lennart Poettering, Red Hat
Colin Guthrie
2015-01-08 14:36:21 UTC
Permalink
Post by Lennart Poettering
Post by Colin Guthrie
Hi,
I'm just playing around with this and making some progress.
I've got a modified dbus-launch that can be slotted in nicely to poke
dbus activated via systemd and teach it about the environment for
subsequent launching. It also pokes systemd --user with the environment
too. It's pretty simply and allows for experimentation without too much
impact.
The issue I currently have is that the dbus daemon itself is now part of
4:devices:/user.slice,1:name=systemd:/user.slice/user-603.slice/session-c2.scope
I guess my question is: Is this OK?
Yes, the idea is that these services become singleton services of the
user, and the sessions ultimately only retain a "stub" process that
does little more than maybe invoke something via systemd and hang
around until log out.
Ahh OK, so this would be a change in the socket activation code in
systemd --user. Once that works, this might just move over the the session?

But dbus-daemon itself might be excluded from that no? I mean the model
is now one-dbus per user and thus it should be shared by all sessions,
therefore it cannot live within a session itself right?

But obviously the stuff *spawned* by dbus should be within a particular
session (i.e. dbus would perhaps have to query logind when spawning to
get the right session - similar in concept to how Kay's patch for polkit
queries logind to get the current display session)?

Would this be magically resolved by kdbus?
Post by Lennart Poettering
Post by Colin Guthrie
It does have repercussions.
In GNOME for example, gnome-terminal is started via dbus activation
(gnome-terminal-server). This means all processes started inside
gnome-terminal actually are part of
cgroup.
Yeah, non-converted bus services will appear as part of
dbus.service. That is ugly of course.
I kinda stopped pushing the per-user stuff until kdbus is done,
because this all resolves itself then, because bus services are then
converted into native systemd services.
Does my comment above about the need for the session^H^H^H^H^H user bus
to query logind to pick the right session apply? If so, how does that
work in a kdbus world?
Post by Lennart Poettering
Post by Colin Guthrie
Is there any problems that people can think of of running such a setup
now without any further compartmentalisation or changes?
Well, it's little tested, and I wish this would just work out of the
box. But again, I am kinda waiting for kdbus to finally be a done deal
before revisiting and pushing for this again...
Hmm, bummer. This is working nicely for me on my machine (albeit things
in the wrong cgroups etc), but this is sort of a pre-requisite for
running PulseAudio via systemd --user socket activation as it needs to
talk to the session dbus.

It would be a shame to not be able to use that until kdbus lands. I'm
tempted to try this but a bit apprehensive as our release is kinda soon
and not sure how much testing this would get...

I could probably modify my dbus-launch patch to just poke systemd --user
env vars and tell it about the DBUS_SESSION_BUS_ADDRESS it creates in
the case where it launches dbus-daemon.... there is a race there that PA
could still be started before dbus-launch but it's quite unlikely in the
normal graphical login case... that might be a half way house and still
allow me to use PA socket activation.

Ho hum!

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/
Simon McVittie
2015-01-08 15:37:34 UTC
Permalink
Post by Colin Guthrie
Post by Lennart Poettering
Yes, the idea is that these services become singleton services of the
user, and the sessions ultimately only retain a "stub" process
But dbus-daemon itself might be excluded from that no? I mean the model
is now one-dbus per user and thus it should be shared by all sessions,
therefore it cannot live within a session itself right?
I think you might be misunderstanding what Lennart said, since you seem
to both have the same model in mind, which is: even if I am logged in
via gdm and via ssh and via getty (3 sessions), there is one systemd
--user associated with my uid (which is not part of any of those
sessions), and one dbus-daemon --session (likewise), and one gpg-agent,
and presumably one PulseAudio, and whatever other misc services are
needed in the background.
Post by Colin Guthrie
But obviously the stuff *spawned* by dbus should be within a particular
session
This is not obvious to me. Anything that can legitimately be used by a
different login session and/or hang around after its originating login
session has finished (e.g. screen, pulseaudio, Telepathy, Rygel, mpd,
...) doesn't really seem like part of that login session any more to me?

I realise there's an oddity here for things that are D-Bus-activated,
but are inextricably linked to one session anyway, because they are X11
applications and cannot outlive their X11 connection (e.g.
gnome-terminal and many other modern GNOME apps).
Post by Colin Guthrie
Would this be magically resolved by kdbus?
Yes and no...

Yes if your concern is that the services are in dbus' cgroup, because
unlike dbus-daemon, kdbus does not have its own service-activation
mechanism; every service-activation is necessarily a systemd activation.
Compare with dbus-daemon, where a service-activation can go one of two
ways: either it has a corresponding systemd service indicated by
SystemdService and systemd is asked to activate it (and it ends up in
its own cgroup), or it's a traditional D-Bus service and dbus-daemon
does it itself (and it ends up in dbus' cgroup). In kdbus-land,
everything behaves a bit like a member of the former category, and the
latter category can't exist (because there's no dbus-daemon).

No if your concern is that gnome-terminal (or whatever GUI app) is not
part of the cgroup corresponding to its X11 session, because AIUI the
same will be true in kdbus.
Post by Colin Guthrie
Post by Lennart Poettering
I kinda stopped pushing the per-user stuff until kdbus is done,
because this all resolves itself then, because bus services are then
converted into native systemd services.
I don't see anything that strictly requires bus services' conversion
into "systemd --user" services to be blocked by kdbus; someone could
probably even write a generator that produced systemd .service from
D-Bus .service.

I can understand that you don't want the particular generator
implementation in systemd to support that, because it's something of a
non-issue in the absence of kdbus, where dbus-daemon already knows how
to do what it is currently doing; it only becomes a necessary
backwards-compatibility step when dbus-daemon is taken out of the picture.
Post by Colin Guthrie
I could probably modify my dbus-launch patch to just poke systemd --user
env vars
Please do not rely on dbus-launch, patched or otherwise, as a medium- or
long-term plan. A future that still contains dbus-launch is not the
world of flying cars I signed up for :-)

S
Dimitri John Ledkov
2015-01-08 16:03:43 UTC
Permalink
On 8 January 2015 at 15:37, Simon McVittie
Post by Simon McVittie
Post by Colin Guthrie
Post by Lennart Poettering
Yes, the idea is that these services become singleton services of the
user, and the sessions ultimately only retain a "stub" process
But dbus-daemon itself might be excluded from that no? I mean the model
is now one-dbus per user and thus it should be shared by all sessions,
therefore it cannot live within a session itself right?
I think you might be misunderstanding what Lennart said, since you seem
to both have the same model in mind, which is: even if I am logged in
via gdm and via ssh and via getty (3 sessions), there is one systemd
--user associated with my uid (which is not part of any of those
sessions), and one dbus-daemon --session (likewise), and one gpg-agent,
and presumably one PulseAudio, and whatever other misc services are
needed in the background.
Hm, this is interesting. Since 14.04, Ubuntu uses upstart to manage
user sessions. At the moment it is for graphical sessions only,
however the semantics are different.

There is upstart --user spawned per session, and everything is under
it. The sessions' logind cgroups are parent of all processes within a
session, and there are sub cgroups as needed for contained
jobs/processes. Thus for three graphical sessions, one has three
upstarts running, three dbus (with different bus ids), etc.

Thus my expectation would be to have a systemd (dbus, etc...) --user
per-session/per-seat, rather than per-uid.

In Ubuntu, we are yet to flash out how to migrate upstart user
sessions to systemd user sessions, for the time being we are
preserving upstart user sessions, even if systemd is pid1.
--
Regards,

Dimitri.

Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
Andrei Borzenkov
2015-01-08 17:15:06 UTC
Permalink
В Thu, 8 Jan 2015 16:03:43 +0000
Post by Dimitri John Ledkov
On 8 January 2015 at 15:37, Simon McVittie
Post by Simon McVittie
Post by Colin Guthrie
Post by Lennart Poettering
Yes, the idea is that these services become singleton services of the
user, and the sessions ultimately only retain a "stub" process
But dbus-daemon itself might be excluded from that no? I mean the model
is now one-dbus per user and thus it should be shared by all sessions,
therefore it cannot live within a session itself right?
I think you might be misunderstanding what Lennart said, since you seem
to both have the same model in mind, which is: even if I am logged in
via gdm and via ssh and via getty (3 sessions), there is one systemd
--user associated with my uid (which is not part of any of those
sessions), and one dbus-daemon --session (likewise), and one gpg-agent,
and presumably one PulseAudio, and whatever other misc services are
needed in the background.
Hm, this is interesting. Since 14.04, Ubuntu uses upstart to manage
user sessions. At the moment it is for graphical sessions only,
however the semantics are different.
There is upstart --user spawned per session, and everything is under
it. The sessions' logind cgroups are parent of all processes within a
session, and there are sub cgroups as needed for contained
jobs/processes. Thus for three graphical sessions, one has three
upstarts running, three dbus (with different bus ids), etc.
Thus my expectation would be to have a systemd (dbus, etc...) --user
per-session/per-seat, rather than per-uid.
How do you manage things that are inherently per-user and not
per-session (like pulse audio, ssh-/gpg-agents)?
Dimitri John Ledkov
2015-01-08 17:48:00 UTC
Permalink
Post by Andrei Borzenkov
В Thu, 8 Jan 2015 16:03:43 +0000
Post by Dimitri John Ledkov
On 8 January 2015 at 15:37, Simon McVittie
Thus my expectation would be to have a systemd (dbus, etc...) --user
per-session/per-seat, rather than per-uid.
How do you manage things that are inherently per-user and not
per-session (like pulse audio, ssh-/gpg-agents)?
E.g. ssh-/gpg-agents -> they are upstart jobs, and thus are started
per-session. They use environment variables to point at the active
agent.

Even on your desktop, you can spawn two agents and use different
SSH_AUTH_SOCK to talk to one or the other.

Ideally such variables could be eliminated in favor of using address
namespacing e.g. always talk to unix:abstract=/tmp/agent -> which is
then point at different things in each of the logind sessions, or
same, or whatever as needed depending on the desired model of
per-users/per-session/per-user-session of behaviour. Kind of like the
dbus is at the moment, one simply talks to well known name and the
implications of who is talking to who and how it's launched and shared
is offloaded to the "session-manager" (*) and the distro policies /
integration.

(*) be it gnome-session, systemd, upstart, etc.
--
Regards,

Dimitri.

Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
Colin Guthrie
2015-01-09 09:56:27 UTC
Permalink
Post by Dimitri John Ledkov
Post by Andrei Borzenkov
В Thu, 8 Jan 2015 16:03:43 +0000
Post by Dimitri John Ledkov
On 8 January 2015 at 15:37, Simon McVittie
Thus my expectation would be to have a systemd (dbus, etc...) --user
per-session/per-seat, rather than per-uid.
How do you manage things that are inherently per-user and not
per-session (like pulse audio, ssh-/gpg-agents)?
E.g. ssh-/gpg-agents -> they are upstart jobs, and thus are started
per-session. They use environment variables to point at the active
agent.
Even on your desktop, you can spawn two agents and use different
SSH_AUTH_SOCK to talk to one or the other.
Ideally such variables could be eliminated in favor of using address
namespacing e.g. always talk to unix:abstract=/tmp/agent -> which is
then point at different things in each of the logind sessions, or
same, or whatever as needed depending on the desired model of
per-users/per-session/per-user-session of behaviour.
You don't really need to use abstract sockets here, you can use known
socket paths in $XDG_RUNTIME_DIR these days as we can rely on it.

As pam_systemd will set XDG_RUNTIME_DIR to /run/user/$UID/ we can easily
just mandate that ssh agent is always on /run/user/$UID/ssh-agent
socket, and forgo any env vars.

We can also then teach ssh-agent to be socket activatable, and then
simply write ssh-agent.socket and ssh-agent.service systemd units
accordingly and it will be autolaunched by systemd on-demand. Teach it
to exit after a timeout and it'll quit and save resources when not
needed too.

This is likely the way forward IMO. Ditto for gpg-agent.

(this isn't really different to what you say in principle, just a little
detail about the implementation)

:)

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/
Tomasz Torcz
2015-01-09 15:26:04 UTC
Permalink
Post by Colin Guthrie
You don't really need to use abstract sockets here, you can use known
socket paths in $XDG_RUNTIME_DIR these days as we can rely on it.
As pam_systemd will set XDG_RUNTIME_DIR to /run/user/$UID/ we can easily
just mandate that ssh agent is always on /run/user/$UID/ssh-agent
socket, and forgo any env vars.
We can also then teach ssh-agent to be socket activatable, and then
simply write ssh-agent.socket and ssh-agent.service systemd units
accordingly and it will be autolaunched by systemd on-demand. Teach it
to exit after a timeout and it'll quit and save resources when not
needed too.
This is likely the way forward IMO. Ditto for gpg-agent.
(this isn't really different to what you say in principle, just a little
detail about the implementation)
For the sake of googlers, there is Envoy (ssh/gpg-agent wrapper with socket activation):
https://github.com/vodik/envoy

(Fedora user can get RPM from my copr: https://copr.fedoraproject.org/coprs/ttorcz/envoy/ )
--
Tomasz Torcz To co nierealne -- tutaj jest normalne.
xmpp: ***@chrome.pl Ziomale na życie mają tu patenty specjalne.
Lennart Poettering
2015-02-02 22:54:49 UTC
Permalink
Post by Dimitri John Ledkov
Post by Andrei Borzenkov
В Thu, 8 Jan 2015 16:03:43 +0000
Post by Dimitri John Ledkov
On 8 January 2015 at 15:37, Simon McVittie
Thus my expectation would be to have a systemd (dbus, etc...) --user
per-session/per-seat, rather than per-uid.
How do you manage things that are inherently per-user and not
per-session (like pulse audio, ssh-/gpg-agents)?
E.g. ssh-/gpg-agents -> they are upstart jobs, and thus are started
per-session. They use environment variables to point at the active
agent.
Are you sure that ssh/gpg agent are happy with being started multiple
times per-user?
Post by Dimitri John Ledkov
Even on your desktop, you can spawn two agents and use different
SSH_AUTH_SOCK to talk to one or the other.
Ideally such variables could be eliminated in favor of using address
namespacing e.g. always talk to unix:abstract=/tmp/agent -> which is
Well, the abstract AF_UNIX namespace is subject to network namespaces,
which means you'd have to run each user in a network namespace of his
own, which however then would mean it would have no network interfaces
except the loopback device...

Abstract namespace sockets are pretty useless these days, and simply
risky due to the namespacing issue. Don't use them.

The ssh/gpg sockets should really move to XDG_RUNTIME_DIR, and nowhere
else.

Lennart
--
Lennart Poettering, Red Hat
Simon McVittie
2015-01-08 17:24:34 UTC
Permalink
Post by Dimitri John Ledkov
There is upstart --user spawned per session, and everything is under
it. The sessions' logind cgroups are parent of all processes within a
session, and there are sub cgroups as needed for contained
jobs/processes. Thus for three graphical sessions, one has three
upstarts running, three dbus (with different bus ids), etc.
Thus my expectation would be to have a systemd (dbus, etc...) --user
per-session/per-seat, rather than per-uid.
This is a conversation about the distinction between a per-(uid,machine)
bus (the "user bus") and a per-login-session bus (the "session bus").
We've had this discussion several times in the past, although perhaps
not involving you personally. I'll follow-up with some "further reading"
links about session bus vs. user bus, but freedesktop.org's mail
archives are a bit of a labyrinth so I wanted to get this sent off
before going looking for the right historical threads.

The "session bus" philosophy is how the D-Bus session bus was designed
to work around a decade ago. It's a consistent conceptual model (...
ish), but it breaks down as soon as you want to do something like leave
a headless Rygel service running after you log out, or interact with
your X11 session's D-Bus services from a ssh or getty login.

It also means you can't use D-Bus names as single-instance mutexes to
avoid "last write wins, earlier writes are lost" (or worse!) data
corruption in the home directory, because it allows more than one D-Bus
session to share a home directory, even in the absence of NFS or
whatever. This was meant to be one of the uses of D-Bus name ownership
semantics, so it's a pity that it has never worked in the general case.

Finally, there is no canonical list of the situations that the session
bus does and doesn't support, so whenever someone raises a bug or
feature request about one of the corner cases, nobody knows whether it's
a bug or a feature request or just wrong. Typical corner cases include:

* I'm in an X11 session and my GUI locks up. I use Ctrl+Alt+F1
and log in at the getty. How do I communicate with X11 session things
over D-Bus, perhaps to disconnect from Telepathy without losing
messages?
* The same, but I ssh in from another machine instead. Same question?
* I'm in an X11 session on aardvark, and I open a terminal
emulator and do "ssh -X badger", then run an app on badger.
For session bus purposes, is it part of my login session on aardvark,
a new login session on badger, an existing login session on badger,
or what? Why?
* The same, but I shared my home directory via NFS.
* The same, but I shared my home directory via NFS, and configured
dbus-daemon to be available over TCP (yes, this is apparently
something that is meant to work).
* I run "su". In the su shell, I run an app that wants to connect to
the D-Bus session bus. Does it connect to my existing session bus,
a new session bus for root, some existing session bus for root,
or what? Why?
* I run "su -". Is it the same as "su"? Why/why not?

In response to concerns like those, various people have promoted the
"user bus" as a replacement for the session bus, or occasionally as a
second parallel bus. Where the session bus is per (uid,login session)
and the system bus is per-machine, the user bus is per (uid,machine).

I personally think having only the user bus (and having
(G_|DBUS_)BUS_TYPE_SESSION connect to it) is the best long-term setup,
because it's easy to understand and does not try to impose isolation
between sessions that are not actually a privilege boundary (same uid,
can ptrace each other, etc.).

Having only the session bus (as we do in e.g. Debian 8) is the next best
thing; it's at least an internally consistent model, even if it does
have a bunch of stupid corner cases.

I think having a session bus *and* a parallel user bus, which some
people have advocated in the past, is worse than having only the session
bus and should be avoided, because message order is not preserved
between distinct buses, and application authors shouldn't be required to
deal with IPC that happens in a non-deterministic order.

As far as I understand it, systemd's kdbus userland is intended to
support a system bus (the equivalent of dbus-daemon --system) and a user
bus, but there is no intention to support traditional session buses,
because the people writing systemd's D-Bus-related code are among those
who think the user bus is the way forward.

Regards,
S
Simon McVittie
2015-01-08 17:51:03 UTC
Permalink
Post by Simon McVittie
This is a conversation about the distinction between a per-(uid,machine)
bus (the "user bus") and a per-login-session bus (the "session bus").
We've had this discussion several times in the past
Some further reading; I knew this conversation was old, I hadn't
realised it was over a decade old.

Most of these are are starting points of threads; the specific emails I
point to are not significant, the thread is what's significant. If you
have limited time, the ones from 2010 are probably the most
information-rich.

https://bugs.freedesktop.org/show_bug.cgi?id=17970
http://lists.freedesktop.org/archives/dbus/2004-June/001216.html
http://lists.freedesktop.org/archives/dbus/2005-January/002101.html
http://lists.freedesktop.org/archives/dbus/2005-September/003396.html
http://lists.freedesktop.org/archives/dbus/2006-March/004439.html
http://lists.freedesktop.org/archives/xdg/2008-February/009251.html
http://lists.freedesktop.org/archives/dbus/2009-November/011909.html
http://lists.freedesktop.org/pipermail/dbus/2010-May/012774.html
http://lists.freedesktop.org/pipermail/dbus/2010-May/012860.html
http://lists.freedesktop.org/archives/dbus/2010-November/013683.html
http://lists.freedesktop.org/archives/systemd-devel/2013-March/009405.html
http://lists.freedesktop.org/archives/dbus/2014-March/016163.html

Regards,
S
Dimitri John Ledkov
2015-01-08 17:42:42 UTC
Permalink
On 8 January 2015 at 17:24, Simon McVittie
Post by Simon McVittie
Post by Dimitri John Ledkov
There is upstart --user spawned per session, and everything is under
it. The sessions' logind cgroups are parent of all processes within a
session, and there are sub cgroups as needed for contained
jobs/processes. Thus for three graphical sessions, one has three
upstarts running, three dbus (with different bus ids), etc.
Thus my expectation would be to have a systemd (dbus, etc...) --user
per-session/per-seat, rather than per-uid.
This is a conversation about the distinction between a per-(uid,machine)
bus (the "user bus") and a per-login-session bus (the "session bus").
We've had this discussion several times in the past, although perhaps
not involving you personally. I'll follow-up with some "further reading"
links about session bus vs. user bus, but freedesktop.org's mail
archives are a bit of a labyrinth so I wanted to get this sent off
before going looking for the right historical threads.
The "session bus" philosophy is how the D-Bus session bus was designed
to work around a decade ago. It's a consistent conceptual model (...
ish), but it breaks down as soon as you want to do something like leave
a headless Rygel service running after you log out, or interact with
your X11 session's D-Bus services from a ssh or getty login.
It also means you can't use D-Bus names as single-instance mutexes to
avoid "last write wins, earlier writes are lost" (or worse!) data
corruption in the home directory, because it allows more than one D-Bus
session to share a home directory, even in the absence of NFS or
whatever. This was meant to be one of the uses of D-Bus name ownership
semantics, so it's a pity that it has never worked in the general case.
Finally, there is no canonical list of the situations that the session
bus does and doesn't support, so whenever someone raises a bug or
feature request about one of the corner cases, nobody knows whether it's
True, hence we only enabled user session management with upstart on
the graphical logins.

However, we also included facilities to join/part a given user session.
Thus one can join a given upstart session id, and control it, query
it's environment and move into that environment.
(Not automated, but there are qa scripts that do that for validation)
Post by Simon McVittie
* I'm in an X11 session and my GUI locks up. I use Ctrl+Alt+F1
and log in at the getty. How do I communicate with X11 session things
over D-Bus, perhaps to disconnect from Telepathy without losing
messages?
* The same, but I ssh in from another machine instead. Same question?
On Ubuntu at the moment this looks in practice something like this:
find UPSTART_SESSION_ID of your tty7 session, export that variable in
your getty shell, then use initctl list-env ("systemctl") to list
environment variables, one of them is DBUS_SESSION_BUS_ADDRESS use
that to communicate with dbus.

In essence it's no different from today world where your getty login
doesn't have your tty7 DBUS_SESSION_BUS_ADDRESS.
Post by Simon McVittie
* I'm in an X11 session on aardvark, and I open a terminal
emulator and do "ssh -X badger", then run an app on badger.
For session bus purposes, is it part of my login session on aardvark,
a new login session on badger, an existing login session on badger,
or what? Why?
Not enabled, but would be new ssh-session on badger.
Post by Simon McVittie
* The same, but I shared my home directory via NFS.
Not tested by me. But e.g. dbus is spawned by upstart without a pid or
anything like that, or uses XDG_RUNTIME_DIR which is unique per
session, and thus not hitting NFS.
Post by Simon McVittie
* The same, but I shared my home directory via NFS, and configured
dbus-daemon to be available over TCP (yes, this is apparently
something that is meant to work).
The second session will fail to start, cause well you can't bind to
same TCP port twice.
This is a distro bug though, as the graphical-distro has it's user
jobs setup to by default to be in good order.
Post by Simon McVittie
* I run "su". In the su shell, I run an app that wants to connect to
the D-Bus session bus. Does it connect to my existing session bus,
a new session bus for root, some existing session bus for root,
or what? Why?
As currently, and in ubuntu case, a new dbus session bus is
autolaunched - standard dbus behaviour. The reason being is that "su"
sessions do not get user-init/logind-session(?!) and thus don't
inherit those things nor launch new ones.
Post by Simon McVittie
* I run "su -". Is it the same as "su"? Why/why not?
Not sure, don't have an answer here. In upstart we did limit
user-sessions to be for non-root/non-system users that can login.
Post by Simon McVittie
In response to concerns like those, various people have promoted the
"user bus" as a replacement for the session bus, or occasionally as a
second parallel bus. Where the session bus is per (uid,login session)
and the system bus is per-machine, the user bus is per (uid,machine).
Right, that would be flexible to address "background user serverish
things" vs "unique user in-my-face things".
Post by Simon McVittie
I personally think having only the user bus (and having
(G_|DBUS_)BUS_TYPE_SESSION connect to it) is the best long-term setup,
because it's easy to understand and does not try to impose isolation
between sessions that are not actually a privilege boundary (same uid,
can ptrace each other, etc.).
Having only the session bus (as we do in e.g. Debian 8) is the next best
thing; it's at least an internally consistent model, even if it does
have a bunch of stupid corner cases.
only the session bus, but per-session though?! If i have two graphical
sessions on tty1 & tty2 they will have different
DBUS_SESSION_BUS_ADDRESS, right?!
Post by Simon McVittie
I think having a session bus *and* a parallel user bus, which some
people have advocated in the past, is worse than having only the session
bus and should be avoided, because message order is not preserved
between distinct buses, and application authors shouldn't be required to
deal with IPC that happens in a non-deterministic order.
As far as I understand it, systemd's kdbus userland is intended to
support a system bus (the equivalent of dbus-daemon --system) and a user
bus, but there is no intention to support traditional session buses,
because the people writing systemd's D-Bus-related code are among those
who think the user bus is the way forward.
I don't have a deep opinion on this, cause I am not competent enough
to comment on it. But I'm sure bits of graphical apps stack would then
need to be adjusted to be seats or at least active_seat aware in
system/user bus configuration. (e.g. pop a window up on
active_seat/session, rather than the one you were
dbus/socket-activated on).
--
Regards,

Dimitri.

Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
Simon McVittie
2015-01-08 19:32:36 UTC
Permalink
Post by Dimitri John Ledkov
On 8 January 2015 at 17:24, Simon McVittie
Post by Simon McVittie
I personally think having only the user bus (and having
(G_|DBUS_)BUS_TYPE_SESSION connect to it) is the best long-term setup,
because it's easy to understand and does not try to impose isolation
between sessions that are not actually a privilege boundary (same uid,
can ptrace each other, etc.).
Having only the session bus (as we do in e.g. Debian 8) is the next best
thing; it's at least an internally consistent model, even if it does
have a bunch of stupid corner cases.
only the session bus, but per-session though?! If i have two graphical
sessions on tty1 & tty2 they will have different
DBUS_SESSION_BUS_ADDRESS, right?!
The difference between those two models is exactly: is that last
sentence true or not?

In the "only the session bus" world: yes, they have distinct session buses.

In the "only the user bus" world: no, DBUS_SESSION_BUS_ADDRESS points to
the user bus, probably unix:path=/run/user/1234/bus (where 1234 is your
uid) or some analogous kdbus thing.

Typical general-purpose distributions are currently (as of e.g. Debian
8) living in the "only the session bus" world. However, it seems that
systemd's kdbus userland is set to have "only the user bus", unless
someone changes its developers' minds; and as far as I know, every
previous attempt to make "dbus-daemon --session" into a systemd --user
service has also followed the "only the user bus" model.
Post by Dimitri John Ledkov
But I'm sure bits of graphical apps stack would then
need to be adjusted to be seats or at least active_seat aware in
system/user bus configuration. (e.g. pop a window up on
active_seat/session, rather than the one you were
dbus/socket-activated on).
Yes, if the graphical environment supports more than one simultaneous
graphical session per uid per machine at all. Another example of
something that would have to change if that situation was to be
supported on a user bus is that the X11 parts of gnome-settings-daemon
(mainly the Xsettings manager) would have to have one instance per X11
display, with different D-Bus names.

As usual, there is a trade-off here. The advocates of a user bus believe
that the benefits of a user bus outweigh the costs (or to put it another
way, that the benefits of multiple session buses do not outweigh their
costs). The advocates of a session bus per $DISPLAY believe the opposite.

S
Cameron Norman
2015-01-09 02:24:56 UTC
Permalink
On Thu, Jan 8, 2015 at 9:42 AM, Dimitri John Ledkov
Post by Dimitri John Ledkov
On 8 January 2015 at 17:24, Simon McVittie
Post by Simon McVittie
* I'm in an X11 session and my GUI locks up. I use Ctrl+Alt+F1
and log in at the getty. How do I communicate with X11 session things
over D-Bus, perhaps to disconnect from Telepathy without losing
messages?
* The same, but I ssh in from another machine instead. Same question?
find UPSTART_SESSION_ID of your tty7 session, export that variable in
your getty shell, then use initctl list-env ("systemctl") to list
environment variables, one of them is DBUS_SESSION_BUS_ADDRESS use
that to communicate with dbus.
It would be easer if there was a variable like
`$XDG_RUNTIME_SESSION_DIR`, which would point to
`$XDG_RUNTIME_DIR/sessions/$sid`. Then you could just change that to
attach to a currently running session, and you could easily visualize
which sessions are running. It would also be nice because services
that do not conflict with themselves when running a second instance
with the same uid (not dconf, but something along the lines of a GUI
shell or gnome-session/upstart) could use it instead of doing their
own session instancing (like upstart does).

Cheers,
--
Cameron Norman
Colin Guthrie
2015-01-09 10:18:57 UTC
Permalink
Post by Cameron Norman
On Thu, Jan 8, 2015 at 9:42 AM, Dimitri John Ledkov
Post by Dimitri John Ledkov
On 8 January 2015 at 17:24, Simon McVittie
Post by Simon McVittie
* I'm in an X11 session and my GUI locks up. I use Ctrl+Alt+F1
and log in at the getty. How do I communicate with X11 session things
over D-Bus, perhaps to disconnect from Telepathy without losing
messages?
* The same, but I ssh in from another machine instead. Same question?
find UPSTART_SESSION_ID of your tty7 session, export that variable in
your getty shell, then use initctl list-env ("systemctl") to list
environment variables, one of them is DBUS_SESSION_BUS_ADDRESS use
that to communicate with dbus.
It would be easer if there was a variable like
`$XDG_RUNTIME_SESSION_DIR`, which would point to
`$XDG_RUNTIME_DIR/sessions/$sid`. Then you could just change that to
attach to a currently running session, and you could easily visualize
which sessions are running.
In a systemd world, you already have loginctl to easily visualise which
sessions are running. It will even tell you if they are text/tty, X11 or
Wayland sessions, show you the processes running etc. etc.

But using a SESSION_DIR like that breaks lots of other nice things, such
as socket activation (unless you also run systemd --session instance
which is certainly not planned!). In the user model, users will have
their systemd --user daemon running and it can listen on all sorts of
sockets in $XGD_RUNTIME_DIR for you and launch the actual services
behind those sockets as needed.

This makes things a lot nicer and should make startup much faster too as
all these agents that are started now can be left until they are needed.

If you introduce this SESSION_DIR concept then this isn't possible.

Now that's not to say each of the things cannot survive in a session
context. It's entirely possible for things like ssh-agent or gpg-agent
etc to run once but internally handle multiple sessions. They can easily
ask logind to which session a calling process belongs (man 3
sd_pid_get_session) and hook into the appropriate gui component.

So yes, the user model might mean changing some plumbing components to
properly support multiple sessions properly, but to be honest many such
components don't work properly with multiple sessions anyway (some do,
but others don't).

I think with clarity going forward, things can be designed with clear
boundaries in mind rather than the myriad of corner cases Simon already
outlined (many of which simply don't have correct answers - it can be
opinion based. I think we need clarity here - whether some of us agree
with the decision or not, so that there are no opinions left - just
specifications!)
Post by Cameron Norman
It would also be nice because services
that do not conflict with themselves when running a second instance
with the same uid (not dconf, but something along the lines of a GUI
shell or gnome-session/upstart) could use it instead of doing their
own session instancing (like upstart does).
While this could be attractive in some instances, I think it's ugly in
others. Things are held together with env vars, or properties on the X11
root window/xsettings (or equiv) and I think it becomes quite messy.

With things designed properly around the user model and a few API calls
for those apps that need to worry about sessions, means that things are
designed better from the ground up.

But to be honest, this could easily be a bikeshed debate and that's not
really why I started this thread :D

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/
Cameron Norman
2015-01-09 20:37:27 UTC
Permalink
Post by Colin Guthrie
Post by Cameron Norman
On Thu, Jan 8, 2015 at 9:42 AM, Dimitri John Ledkov
Post by Dimitri John Ledkov
On 8 January 2015 at 17:24, Simon McVittie
Post by Simon McVittie
* I'm in an X11 session and my GUI locks up. I use Ctrl+Alt+F1
and log in at the getty. How do I communicate with X11 session things
over D-Bus, perhaps to disconnect from Telepathy without losing
messages?
* The same, but I ssh in from another machine instead. Same question?
find UPSTART_SESSION_ID of your tty7 session, export that variable in
your getty shell, then use initctl list-env ("systemctl") to list
environment variables, one of them is DBUS_SESSION_BUS_ADDRESS use
that to communicate with dbus.
It would be easer if there was a variable like
`$XDG_RUNTIME_SESSION_DIR`, which would point to
`$XDG_RUNTIME_DIR/sessions/$sid`. Then you could just change that to
attach to a currently running session, and you could easily visualize
which sessions are running.
In a systemd world, you already have loginctl to easily visualise which
sessions are running. It will even tell you if they are text/tty, X11 or
Wayland sessions, show you the processes running etc. etc.
But using a SESSION_DIR like that breaks lots of other nice things, such
as socket activation (unless you also run systemd --session instance
which is certainly not planned!). In the user model, users will have
their systemd --user daemon running and it can listen on all sorts of
sockets in $XGD_RUNTIME_DIR for you and launch the actual services
behind those sockets as needed.
I apologize my comment was a little off topic because I was referring
to setups like upstart --session, not systemd --user. Since upstart
--session (or a theoretical, and likely to remain so, systemd
--session) would be aware of that, it could perform socket activation
correctly.
Post by Colin Guthrie
Post by Cameron Norman
It would also be nice because services
that do not conflict with themselves when running a second instance
with the same uid (not dconf, but something along the lines of a GUI
shell or gnome-session/upstart) could use it instead of doing their
own session instancing (like upstart does).
While this could be attractive in some instances, I think it's ugly in
others. Things are held together with env vars, or properties on the X11
root window/xsettings (or equiv) and I think it becomes quite messy.
With things designed properly around the user model and a few API calls
for those apps that need to worry about sessions, means that things are
designed better from the ground up.
But to be honest, this could easily be a bikeshed debate and that's not
really why I started this thread :D
Yeah I was suggesting simply making the session paradigm a little
cleaner by holding it together with only one env var instead of
multiple, not looking to discredit the user paradigm.

Cheers,
--
Cameron
Lennart Poettering
2015-02-02 23:13:17 UTC
Permalink
Post by Cameron Norman
On Thu, Jan 8, 2015 at 9:42 AM, Dimitri John Ledkov
Post by Dimitri John Ledkov
On 8 January 2015 at 17:24, Simon McVittie
Post by Simon McVittie
* I'm in an X11 session and my GUI locks up. I use Ctrl+Alt+F1
and log in at the getty. How do I communicate with X11 session things
over D-Bus, perhaps to disconnect from Telepathy without losing
messages?
* The same, but I ssh in from another machine instead. Same question?
find UPSTART_SESSION_ID of your tty7 session, export that variable in
your getty shell, then use initctl list-env ("systemctl") to list
environment variables, one of them is DBUS_SESSION_BUS_ADDRESS use
that to communicate with dbus.
It would be easer if there was a variable like
`$XDG_RUNTIME_SESSION_DIR`, which would point to
`$XDG_RUNTIME_DIR/sessions/$sid`. Then you could just change that to
attach to a currently running session, and you could easily visualize
which sessions are running. It would also be nice because services
that do not conflict with themselves when running a second instance
with the same uid (not dconf, but something along the lines of a GUI
shell or gnome-session/upstart) could use it instead of doing their
own session instancing (like upstart does).
I am not convinced that we need special support for this really. I
fail to see the usecase. I mean, it's usually the background stuff
that listens on sockets, and all that background stuff tends to be
more per-user than per-session. I fail to see which service would
really need a per-session listening socket... And if there is one,
then using $XDG_RUNTIME_DIR/foobar.$XDG_SESSION_ID should be good
enough...

Lennart
--
Lennart Poettering, Red Hat
Lennart Poettering
2015-02-02 23:02:20 UTC
Permalink
Post by Dimitri John Ledkov
Post by Simon McVittie
It also means you can't use D-Bus names as single-instance mutexes to
avoid "last write wins, earlier writes are lost" (or worse!) data
corruption in the home directory, because it allows more than one D-Bus
session to share a home directory, even in the absence of NFS or
whatever. This was meant to be one of the uses of D-Bus name ownership
semantics, so it's a pity that it has never worked in the general case.
Finally, there is no canonical list of the situations that the session
bus does and doesn't support, so whenever someone raises a bug or
feature request about one of the corner cases, nobody knows whether it's
True, hence we only enabled user session management with upstart on
the graphical logins.
However, we also included facilities to join/part a given user session.
Thus one can join a given upstart session id, and control it, query
it's environment and move into that environment.
(Not automated, but there are qa scripts that do that for
validation)
I'd ver very careful with concepts of "joining" and "parting"
sessions. A session is made up of tons of different things, and some
are hard to see or even impossible to alter. For example, if you have
a MAC system like selinux you cannot easily patch around in the labels
during runtime if you want to change it orthogonally to normal process
inheritance. But it's not just that. For example, you cannot override
audit login/session ids after you wrote them once for a process and
its children. This means, if you introduce concepts for joining and
parting, then your audit traces start to deviate from the rest of the
system's idea of a session, and then things get really annoying.

I'd really try to stay away from concepts of parting/joining, it's
hard to know and patch all process attribs that requires, and even
impossible for some of them.

Lennart
--
Lennart Poettering, Red Hat
Lennart Poettering
2015-02-02 22:47:26 UTC
Permalink
On Thu, 08.01.15 14:36, Colin Guthrie (***@colin.guthr.ie) wrote:

(Sorry for the late reply. Still busy processing all the queued
mails. I figure half of what this mail was about was already discussed
on the hackfest last friday, but in case something was missing, here
we go)
Post by Colin Guthrie
Post by Lennart Poettering
Post by Colin Guthrie
Hi,
I'm just playing around with this and making some progress.
I've got a modified dbus-launch that can be slotted in nicely to poke
dbus activated via systemd and teach it about the environment for
subsequent launching. It also pokes systemd --user with the environment
too. It's pretty simply and allows for experimentation without too much
impact.
The issue I currently have is that the dbus daemon itself is now part of
4:devices:/user.slice,1:name=systemd:/user.slice/user-603.slice/session-c2.scope
I guess my question is: Is this OK?
Yes, the idea is that these services become singleton services of the
user, and the sessions ultimately only retain a "stub" process that
does little more than maybe invoke something via systemd and hang
around until log out.
Ahh OK, so this would be a change in the socket activation code in
systemd --user. Once that works, this might just move over the the session?
Note sure I follow on this one. Which socket activation code do you
precisely mean?
Post by Colin Guthrie
But dbus-daemon itself might be excluded from that no? I mean the model
is now one-dbus per user and thus it should be shared by all sessions,
therefore it cannot live within a session itself right?
Well, I mean, we only ever put this altogether for kdbus, where
systemd itself is the one setting up the bus. But yeah, if you want to
make this all work with dbus-daemon, then you would have to teach it
bus activation support. Most likely that should be really easy, and
just involves also installing a dbus.socket and dbus.service into the
user unit dir.
Post by Colin Guthrie
But obviously the stuff *spawned* by dbus should be within a particular
session (i.e. dbus would perhaps have to query logind when spawning to
get the right session - similar in concept to how Kay's patch for polkit
queries logind to get the current display session)?
No, all stuff should be forked off systemd, and hence be outside of
any immediate user ssession, and instead be a per-user singleton.

Lennart
--
Lennart Poettering, Red Hat
Simon McVittie
2015-02-03 11:52:07 UTC
Permalink
Post by Lennart Poettering
Well, I mean, we only ever put this altogether for kdbus, where
systemd itself is the one setting up the bus. But yeah, if you want to
make this all work with dbus-daemon, then you would have to teach it
bus activation support. Most likely that should be really easy, and
just involves also installing a dbus.socket and dbus.service into the
user unit dir.
It is this easy, and I do think dbus should support this model, as I
outlined in a longer mail on Friday.
https://bugs.freedesktop.org/show_bug.cgi?id=61301 (reviews welcome).

The harder part is getting environment variables pushed around, for
which I don't have a complete patch yet (but I'm going to work on that
within the next couple of weeks).

S
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
Lennart Poettering
2015-02-03 12:08:23 UTC
Permalink
Post by Simon McVittie
Post by Lennart Poettering
Well, I mean, we only ever put this altogether for kdbus, where
systemd itself is the one setting up the bus. But yeah, if you want to
make this all work with dbus-daemon, then you would have to teach it
bus activation support. Most likely that should be really easy, and
just involves also installing a dbus.socket and dbus.service into the
user unit dir.
It is this easy, and I do think dbus should support this model, as I
outlined in a longer mail on Friday.
https://bugs.freedesktop.org/show_bug.cgi?id=61301 (reviews welcome).
The harder part is getting environment variables pushed around, for which I
don't have a complete patch yet (but I'm going to work on that within the
next couple of weeks).
Do you need more than "systemctl import DISPLAY"?

Lennart
--
Lennart Poettering, Red Hat
Simon McVittie
2015-02-03 12:12:18 UTC
Permalink
Post by Lennart Poettering
Do you need more than "systemctl import DISPLAY"?
That's the main one, but for it to not be a regression on current
general-purpose distributions, the equivalent of `systemctl
import-environment` needs to upload into the dbus-daemon too (so that
D-Bus-activated, non-systemd services will get the variables), and there
are a bunch of other variables set in /etc/X11/Xsession.d or equivalent
that should also be uploaded if present.
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
Colin Guthrie
2015-01-09 10:26:33 UTC
Permalink
Post by Colin Guthrie
I "solved" this by adding a user unit for gnome-termnial-server and
making dbus use systemd activation for it, but that just moves it to a
different cgroup. I guess it's OK like this.
Just as a minor curiosity related to this bit...

I discovered today that handing this particular process over to as
systemd --user unit is a bit broken!

It seems that gnome-terminal-server will exit when the last
gnome-terminal dies. If you have started any programs in the background
in the terminal (xeyes&, or even screen) and then close all your
gnome-terminal processes, the main process of the cgroup becomes empty
and then all the child processes are (correctly) reaped by systemd --user

Fun!

The screen example is a tough one here tho' with gnome-terminal-server.
Since I removed it's own systemd unit, it will now live in the dbus
daemon's cgroup and depending when the daemon dies, it not survive a
logout... will have to check that! Might be OK tho'.

Playing with systemd --user is fun :)

C
--
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/
Mantas Mikulėnas
2015-01-09 10:31:53 UTC
Permalink
I guess you could use KillMode= for this?

Or, actually, dbus.service doesn't stop on logout, does it?...

For tmux, I have a tmux.service that runs:

ExecStart=/usr/bin/tmux start-server \x3B wait-for systemd

ExecStop=/usr/bin/tmux wait-for -S systemd \x3B kill-server

screen has no equivalent though.
Colin Guthrie
2015-01-09 12:18:51 UTC
Permalink
Post by Mantas Mikulėnas
I guess you could use KillMode= for this?
I don't think so. This would mean the unit would still be alive even
although the main process died and when I next tried to open a
gnome-terminal, it would try and speak to the dbus service again and
then dbus would try and spawn it but systemd would say "it's already
running" and not actually run a new gnome-terminal-server process.

I've not tried this in practice, but I think the above is the expected
behaviour here.
Post by Mantas Mikulėnas
Or, actually, dbus.service doesn't stop on logout, does it?...
I think it will stick around, but so far I've not really been testing it
much in terms of clean logout/log back in again. Just that it "runs" OK :)
Post by Mantas Mikulėnas
ExecStart=/usr/bin/tmux start-server \x3B wait-for systemd
ExecStop=/usr/bin/tmux wait-for -S systemd \x3B kill-server
screen has no equivalent though.
If it does keep running then this is somewhat moot, but nice to know
tmux has a solution :)

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/
Lennart Poettering
2015-02-02 23:19:28 UTC
Permalink
Post by Colin Guthrie
Post by Mantas Mikulėnas
I guess you could use KillMode= for this?
I don't think so. This would mean the unit would still be alive even
although the main process died and when I next tried to open a
gnome-terminal, it would try and speak to the dbus service again and
then dbus would try and spawn it but systemd would say "it's already
running" and not actually run a new gnome-terminal-server process.
Not really, if you use KillMode=main for this, then systemd simply
doesn't care for any remaining processes, except for the main one, and
the unit's state would not be affected in any way by those
processes. The right thing should happen.

Lennart
--
Lennart Poettering, Red Hat
Lennart Poettering
2015-02-02 23:17:13 UTC
Permalink
Post by Colin Guthrie
Post by Colin Guthrie
I "solved" this by adding a user unit for gnome-termnial-server and
making dbus use systemd activation for it, but that just moves it to a
different cgroup. I guess it's OK like this.
Just as a minor curiosity related to this bit...
I discovered today that handing this particular process over to as
systemd --user unit is a bit broken!
It seems that gnome-terminal-server will exit when the last
gnome-terminal dies. If you have started any programs in the background
in the terminal (xeyes&, or even screen) and then close all your
gnome-terminal processes, the main process of the cgroup becomes empty
and then all the child processes are (correctly) reaped by systemd --user
Fun!
The screen example is a tough one here tho' with gnome-terminal-server.
Since I removed it's own systemd unit, it will now live in the dbus
daemon's cgroup and depending when the daemon dies, it not survive a
logout... will have to check that! Might be OK tho'.
Playing with systemd --user is fun :)
Ideally gnome-terminal would open a user scope unit for each of its
tabs. This would allow them to survive, even without patching
KillMode= for the g-t-s service...

Lennart
--
Lennart Poettering, Red Hat
Continue reading on narkive:
Loading...