Re: [systemd-devel] User sessions, session buses, user buses
On 03/02/15 10:16, Stef Bon wrote: I've never understood why the session bus is started through dbus-launch. If we move from a per-login-session to a per-user-session bus, then it won't be; dbus-launch will become solely for the people who run twm under xdm or something, but who still want to run (say) Firefox. Leave it to the login manager (not PAM), or provide the socket and activate the session bus only when some app is connecting to it, which can be a graphical session, but may be also a console. That is what I plan to do. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] User sessions, session buses, user buses
2015-01-30 9:30 GMT+01:00 Simon McVittie simon.mcvit...@collabora.co.uk: In principle, a PAM module or something could ensure that we have a dbus-daemon per login session, even tty/ssh/cron login sessions (which all go through PAM). In practice, nobody has ever cared enough to implement this, so we're left with D-Bus autolaunch, which can't actually work for tty sessions and had bad side-effects from its attempts to do so, so I disabled it 3 years ago in favour of recommending that users requiring a D-Bus session should start their own and manage its lifetime themselves e.g. with dbus-run-session(1). Hi all, I've never understood why the session bus is started through dbus-launch. Leave it to the login manager (not PAM), or provide the socket and activate the session bus only when some app is connecting to it, which can be a graphical session, but may be also a console. Stef ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] User sessions, session buses, user buses
Hi On Fri, Jan 30, 2015 at 9:30 AM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: [For those who are there, I'll be at the system hackfest today and at FOSDEM this weekend, so if you are interested in these topics, please talk to me about them; I'll try to summarize discussion to these lists. For those not there, I'll try to keep up with responses via email and raise any interesting points in person.] I've recently been looking into D-Bus' interaction with X session startup, systemd --user, upstart --user, and the definition of a session. Every few months or years there is an attempt to sort out whether D-Bus has a user bus or a session bus or what. Here is another, with particular reference to systemd and potentially kdbus. Terminology === login session - A *login session* is as follows: when you log in to *dm, that starts a *graphical login session* which lasts until you log out. When you log in on a virtual console or via ssh or something, that starts a *non-graphical login session*. Background processes like cron or screen might also be non-graphical login sessions. A non-graphical login session might become graphical by running startx or similar. We don't support turning text-sessions into graphical sessions (like 'startx' and friends). It works in some scenarios, but is strongly frowned upon. Furthermore, VT sessions should really be treated like graphical sessions. From a technical viewpoint, there is no difference. And with things like kmscon or systemd-console, you really *have* to treat it the same as graphical logins. In a systemd-logind environment, login sessions have an ID which is made available to in-session processes in the XDG_SESSION_ID environment variable. If the Linux auditing feature is enabled, the XDG_SESSION_ID equals the audit session ID (/proc/self/sessionid). If not, there is no audit session ID, so systemd-logind makes up a sequential XDG_SESSION_ID and uses that. seat A seat is a set of displays, input devices etc. attached to a machine. Most machines have one seat seat0, which occupies all the devices. 'all the devices' is not exactly right. We still distinguish between 'seated' devices and 'non-seated' devices. That is, some devices are always global and never assigned to a seat (like power-buttons, though that particular example might even be broken right now). But yes, all 'seated' devices are assigned to 'seat0' implicitly, if not set otherwise. By attaching additional devices via something like http://plugable.com/products/ud-160-m you can construct a multi-seat machine. user-session I don't think there is a standard term for this so I'm making one up. The XDG_RUNTIME_DIR specification says that there is at most one XDG_RUNTIME_DIR per uid per machine, that it is created at the beginning of the user's first login session, and that it is removed at the end of a login session if no other login sessions remain for that uid. systemd-logind implements those semantics, and also runs a `systemd --user` for the lifetime of the user-session. Ubuntu previously used libpam-xdg-runtime to provide compatible semantics without systemd. The resulting situation looks something like this (assume all the sessions shown are under the same uid): \ \\ login | user- || session | \ session || - overlapping login session c42 23 | login | ||shares the user-session with 23 / session | || - 23 ends but c42 keeps u.-session c42 | ||alive \ | || - 57 begins, shares u.-sess. login | / || - c42 ends, 57 keeps user-session session | ||alive 57 | || / // no more l.sessions, u.-session ends \ \\ new l.session, u.-session starts login | user- || session | session || ... . ... .. user-sessions do not have any meaningful identifier apart from their owner's uid (strictly speaking, the owner's loginuid, i.e. the user who initially logged in, even if they su). They do not need another identifier, because by definition there is only one per uid at a time. Impact on D-Bus === There are two models for how the D-Bus session bus, which is designed to be per high-level session (whatever that means), can work in a world with user-sessions. Last time this was discussed, Havoc had the useful insight that this is not really a question about D-Bus, it's a question about how you build OSs, and in particular how you model sessions. (Up to) one high-level session per login The first model, which is how it traditionally worked (before there was such a thing
Re: [systemd-devel] User sessions, session buses, user buses
On Fri, 30.01.15 09:30, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: user-session I don't think there is a standard term for this so I'm making one up. The XDG_RUNTIME_DIR specification says that there is at most one XDG_RUNTIME_DIR per uid per machine, that it is created at the beginning of the user's first login session, and that it is removed at the end of a login session if no other login sessions remain for that uid. systemd-logind implements those semantics, and also runs a `systemd --user` for the lifetime of the user-session. Ubuntu previously used libpam-xdg-runtime to provide compatible semantics without systemd. The resulting situation looks something like this (assume all the sessions shown are under the same uid): \ \\ login | user- || session | \ session || - overlapping login session c42 23 | login | ||shares the user-session with 23 / session | || - 23 ends but c42 keeps u.-session c42 | ||alive \ | || - 57 begins, shares u.-sess. login | / || - c42 ends, 57 keeps user-session session | ||alive 57 | || / // no more l.sessions, u.-session ends \ \\ new l.session, u.-session starts login | user- || session | session || ... . ... .. user-sessions do not have any meaningful identifier apart from their owner's uid (strictly speaking, the owner's loginuid, i.e. the user who initially logged in, even if they su). They do not need another identifier, because by definition there is only one per uid at a time. Small addition: these super-sessions are slightly modulated by the linger boolean setting that logind manages per-user. If that boolean is true the user's super-session stays alive from boot to shutdown. Digression: (at least some) users and developers don't want that Adding in here: note that firefox and some other apps actually lock thheir configuration directory, so that it effectively a singleton program per-user anyway. One of the most important apps of the user is hence per-use anyway, even if started in a per-session context. It's already been discussed multiple times on the list and apparently a user bus is too confusing or not really useful unless you make it a user bus shared across a network cluster. I don't agree, and I think that the consequence of this stance will be a proliferation of hacks like the one I just sketched out (not to mention even grosser hacks like Ubuntu's ACPI scripts grepping the environment of the user's processes in /proc to find their session bus to tell their screensaver to lock). Not convinced that the ACPI thing is a good example. It's not a confusion about session/user contexts, but more a confusion about privileged code calling into unprvileged code, which should never happen. This leaves the problem that, if you have chosen the user-session-centric model, current D-Bus doesn't actually work very well: we have dbus-launch and dbus-run-session for login-session-centric D-Bus, but if you want to make D-Bus user-session-centric, you need to resort to third-party user bus units like user-session-units, which float around Github and somehow never make it upstream. I'm now on my third unrelated work project that contains a copypaste of dbus.socket and dbus.service, and I'm sure my colleagues have others - this is not the flying car future I signed up for. So I would like to get this stuff upstream into dbus.git. So that the people who are happy with the complexities of the current arrangement can remain happy, here is how I intend it to work: * ./configure --disable-user-bus: you get a login-session-centric world * ./configure --enable-user-bus: you get a user-session-centric world * configure either way and selectively install/delete files: you can either have a login-session-centric or user-session-centric world, depending what you install. (This is so I can have dbus-user-bus and dbus-x11 binary packages in Debian, where the answer to do A or do B? is always both!, without having to compile everything twice; the GNOME metapackage could eventually depend on dbus-user-bus.) So far our logic in systemd was to simply set the $DBUS_SESSION_BUS_ADDRESS to the user bus address, to redirect all access to the session bus to the user bus. Sadly, not all the issues have been resolved yet. The biggest is environment variables: on existing systems there is an expectation that environment variables set by *dm, PAM, or /etc/X11/Xsession.d (or the non-Debian equivalent) will be propagated into every
Re: [systemd-devel] User sessions, session buses, user buses
On Sat, 31.01.15 09:43, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: Losing DBUS_SESSION_BUS_ADDRESS was part of the point of this thread. BTW: DBUS_SESSION_BUS_ADDRESS we currently set on kdbus systems from pam_systemd. That way we can be sure it is set for all the user's sessions. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] User sessions, session buses, user buses
On Fri, 30.01.15 22:53, Elias Probst (m...@eliasprobst.eu) wrote: On 01/30/2015 09:30 AM, Simon McVittie wrote: Remaining issue: environment variables == […] As a short-term solution, I'm tempted to write that tool, but make it only upload a whitelisted set of variables automatically, and say if you install dbus-user-bus, you are expected to run this tool from your ~/.xsession if you need it. IMHO, env variables are something we should get rid of in the long term. It might be fine for now to provide some legacy-compatibility mechanisms (like your not-yet-written tool), but to me environment variables are something straight out of the dark ages. I think in the long-run we should not use environment variables for all these things in the default codepaths. However, the user always needs the ability to set some if he desires to do so. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] User sessions, session buses, user buses
On Mon, 02.02.15 10:22, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: plus the obvious ones set by *dm, such as DISPLAY, or by PAM. Similarly, a user's ~/.xsession can set arbitrary variables - mine sets CCACHE_DIR, EDITOR, MPD_HOST and XDG_CONFIG_DIRS, among others. The naive implementation would be to run a tool at the end of /etc/X11/Xsession.d that uploads all of these into `dbus-daemon --session` (if used) and into `systemd --user` (if used). However, not all environment variables set in such scripts are suitable for that use: notably, XDG_SESSION_ID from the login session should not be copied into activated processes that exist outside any login session. The rest of the email thread is adequate. I would like to experiment with a user-bus, potentially in a transient manner to have 3 buses: system, user, session busses. And migrate things from session to user bus experiment as to how much stuff breaks. I think being explicit about session vs user bus would avoid confusion, and will help manifest bugs have a clear migration plan. E.g. when org.freedesktop.Telepathy / ca.desrt.dconf moves to user bus, things should know how to start talking to Telepathy/dconf over user bus. I'd be very careful with running things with three instead of two busses, since most user services only open one bus connection, and they assume they find all the user's services on that one connection. If you now intrdouce a seperate user and session bus, you will have to patch all those apps to keep connections open to both busses, and individually check for each bus call they make which bus they need to do that on. I am pretty sure the going for 3 busses, instead of 2 is not worth the effort and much much more work than just redefining session to user, the way we currently try to do in the kdbus context. Note that we test this per-user bus daily, since its the default mode of operation if you boot with kdbus turned on. For that, simply build the kdbus kernel modules as well as systemd with kdbus. Then boot with kdbus on the kernel cmdline and all should be good. We now ship with all the necessary bits in systemd git to make this just work. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] User sessions, session buses, user buses
On 30 January 2015 at 08:30, Simon McVittie simon.mcvit...@collabora.co.uk wrote: Remaining issue: environment variables == Sadly, not all the issues have been resolved yet. The biggest is environment variables: on existing systems there is an expectation that environment variables set by *dm, PAM, or /etc/X11/Xsession.d (or the non-Debian equivalent) will be propagated into every process in the session. In a brief survey of about half the Xsession.d scripts in Debian, I identified these environment variables: * PULSE_SERVER * ESPEAKER * XDG_DATA_HOME, XDG_DATA_DIRS * each variable printed by locale(1) * VDPAU_DRIVER * GTK_IM_MODULE, QT_IM_MODULE, QT4_IM_MODULE, CLUTTER_IM_MODULE, XMODIFIERS * GTK_MODULES And one shall not forget GNOME_DESKTOP_SESSION_ID=this-is-deprecated for a certain C++ toolkit to not look like it's 1995. ;-) plus the obvious ones set by *dm, such as DISPLAY, or by PAM. Similarly, a user's ~/.xsession can set arbitrary variables - mine sets CCACHE_DIR, EDITOR, MPD_HOST and XDG_CONFIG_DIRS, among others. The naive implementation would be to run a tool at the end of /etc/X11/Xsession.d that uploads all of these into `dbus-daemon --session` (if used) and into `systemd --user` (if used). However, not all environment variables set in such scripts are suitable for that use: notably, XDG_SESSION_ID from the login session should not be copied into activated processes that exist outside any login session. The rest of the email thread is adequate. I would like to experiment with a user-bus, potentially in a transient manner to have 3 buses: system, user, session busses. And migrate things from session to user bus experiment as to how much stuff breaks. I think being explicit about session vs user bus would avoid confusion, and will help manifest bugs have a clear migration plan. E.g. when org.freedesktop.Telepathy / ca.desrt.dconf moves to user bus, things should know how to start talking to Telepathy/dconf over user bus. Looking at the stuff that I have on my session dbus, I see quite a few things that do interract with DISPLAY=:0, or rather create GUI windows and expect them to appear in the right place, as in on the currently active seat. Similarly they would need to be migrated/restarted if we ever allow multiple graphical search for a single UID. I wonder if this is at all an actual problem, maybe all current/sophisticated dbus-heavy DEs cannot in fact have multiple graphical sessions for the same UID, in which case switching to user bus today is non-regressing (given that current active graphical session cannot migrate a seat (?! not sure if this)). Going down this rabbit-hole, the only difference between current session-bus (e.g. where under gdm only one graphical login is allowed per UID) and the user-bus seems to be the life-time of the bus (tied from first login until last login V.S. X11 started and finished). That means that dbus-activated services have to simply become seat aware, and know that if they were started on a non-graphical seat, later on active seat might be graphical and thus they should migrate/recreate/create GUI windows on currently active seat - or across all seats if that's appropriate. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] User sessions, session buses, user buses
On 02/02/15 10:22, Dimitri John Ledkov wrote: I would like to experiment with a user-bus, potentially in a transient manner to have 3 buses: system, user, session busses. I still think it's a bad idea to have both a user bus and a session bus. Having things on the wrong bus is definitely an API break, and having processes' messages be out-of-order will break application expectations (message order is guaranteed to be a consistent total ordering within one bus, but you can't even rely on causal ordering across multiple buses). E.g. when org.freedesktop.Telepathy / ca.desrt.dconf moves to user bus, things should know how to start talking to Telepathy/dconf over user bus. If you have both buses, this is a flag-day API break for each thing that moves. Please don't go there if you want to reach a user bus in a finite time. If you only have a session bus, where session is taken to mean either login session or user-session/super-session depending on a choice made by the OS integrator and/or sysadmin, you don't get that problem. I wonder if this is at all an actual problem, maybe all current/sophisticated dbus-heavy DEs cannot in fact have multiple graphical sessions for the same UID, in which case switching to user bus today is non-regressing (given that current active graphical session cannot migrate a seat (?! not sure if this)). GNOME (at least, if you have the full GNOME suite including gdm) specifically does not support more than one graphical session per seat: if you are logged in (with screen locked) on tty7, and you type your username and password into a Switch User gdm prompt on tty8, gdm will just switch to tty7 and unlock your screen. I think this is a perfectly reasonable model. I don't know about multiple seats as the same user, but I suspect that, in practice, it doesn't work very well (if at all) and in any case, why would you? You are only physically in one place after all :-) I believe the situation last time we discussed this was that KDE does support more than one simultaneous graphical session, but Thiago was unsure whether that was by policy or coincidence. Going down this rabbit-hole, the only difference between current session-bus (e.g. where under gdm only one graphical login is allowed per UID) and the user-bus seems to be the life-time of the bus (tied from first login until last login V.S. X11 started and finished). Yes. This is part of the reasoning behind the mental model that Havoc proposed last time this was discussed: this is not about the D-Bus maintainers deciding how long a D-Bus bus lasts, but about OS integrators deciding how long a session lasts (or to put it another way, which of the multiple possible definitions of session should be the one used for D-Bus). When you think of it like that, the decision point becomes whether the OS integrator wants: * dbus-launch manages one session bus per X11 session (current reality, and apparently some people strongly prefer it this way) * dbus.socket/dbus.service manages one session bus per user-session/super-session (I anticipate that e.g. Fedora and GNOME-Continuous will probably make this simplification mandatory) * punt the decision to the sysadmin via whether an optional dbus-user-bus.deb, or RPM equivalent, is installed (I suspect I will have to support both ways for Debian for a while) Over time, as GUI things adjust to the 'systemd --user'-style model, I anticipate that the disadvantages of the user-session bus will decrease and its advantages will increase; maybe one day nobody will use dbus-launch and it can be deleted. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] User sessions, session buses, user buses
On 30/01/15 22:53, Elias Probst wrote: IMHO, env variables are something we should get rid of in the long term. It might be fine for now to provide some legacy-compatibility mechanisms (like your not-yet-written tool), but to me environment variables are something straight out of the dark ages. Environment variables are specified by POSIX, also available in Windows, and one of the few easy ways for information to inherit from a parent process to a child process without the child process needing to do anything explicitly. I don't think they're going to go away, however much you might want them to - the long tail of (mostly TUI) programs that use them is very long indeed. I do agree that the number of them that are necessary should go down over time (and my distro of choice, Debian, has a policy of everything we ship should be usable without manually setting magic environment variables), but I don't think it is likely to go down to zero. The long-term goal (also in a world where a graphical session is managed as a systemd user-session), the information provided until now by an environment variable should be queried dynamically by e.g. a D-Bus call to the component responsible for providing the relevant information. Environment variables do several different things. Having a quick skim through my `env` output, here are some distinct categories: We talked about LANG a bit at the hackfest, and the consensus seemed to be that something better should happen, but nobody was sure exactly what. I don't set LC_* but if I did, they'd be in the same category. Losing DBUS_SESSION_BUS_ADDRESS was part of the point of this thread. :-) Similarly, DISPLAY, GPG_AGENT_INFO, SSH_AUTH_SOCK should be able to go away one day, when those things grow support for XDG_RUNTIME_DIR-based socket-activation. XAUTHORITY can go away eventually too, even in X11 environments, in favour of xhost +SI:localuser:smcv (which in fact gdm already does). DEBEMAIL, LESS, LS_COLORS, PYTHONSTARTUP, SHELL, SSH_ASKPASS, VISUAL are configuration, and could in principle be read from a dotfile instead (although good luck porting every last consumer of EDITOR, SHELL and VISUAL to your new world order - e.g. Debian has more than 37k packages). XDG_SEAT, XDG_SESSION_ID, XDG_VTNR are properties of my login-session, not my user-session or my home directory, so you can't write them to either XDG_RUNTIME_DIR or a dotfile because both would be the wrong scope. XDG_RUNTIME_DIR has to be an environment variable because you can't very well read it from the XDG_RUNTIME_DIR :-) S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] User sessions, session buses, user buses
On 30/01/15 09:30, Simon McVittie wrote:
user-session
I don't think there is a standard term for this so I'm making one up.
Notes from the hackfest: A few people called these super-sessions when
we discussed them. I preferred user-session tbh, but if people want to
standardize on calling them super-sessions that's fine.
If people want to put work into this model, we could do a lot better
than we do now; for instance, the bus socket could be
unix:path=${XDG_RUNTIME_DIR}/sessions/${XDG_SESSION_ID}/bus (but with
the necessary escaping) on systems where those variables are set, rather
than messing about with $TMPDIR.
Please open an enhancement-severity bug against dbus if you want this,
and I can talk you through the right places to patch; it would not be
rocket science, and if people have use-cases for it, I would be OK with
merging it even though I personally prefer the user-session model.
Similarly, if you leave a screen/tmux session detached and running
in the background, systemd is fine with that: its view of the world
is that there are processes left over from your previous login session,
keeping the login session alive in closing state, with the consequence
that the user-session remains alive too
Notes from the hackfest: Everyone seems to think screen/tmux/... should
use PAM to register themselves as first-class login sessions in their
own right, if allowed by the sysadmin. That would also work fine.
Under X11, that might well be the best we can do, because typical
X11 applications can't cope with being asked to put windows on more
than one $DISPLAY (although I've heard rumours that Emacs can, which
would make Emacs an ideal candidate to be a user-session service).
Under Wayland or similar future cleverness, hopefully there'll be
some way for a new login on a new seat to steal all the windows
from the inactive seat, or some way to merge both seats into
one big virtual display if the same person is using both (AIUI this
is what GNOME designers want to do), or some other clever solution.
Notes from the hackfest: Lennart's long-term idea is to have a singleton
X server (or Wayland equivalent) per uid, and hotplug output devices
to it as the user logs in/out on different seats (or remotely via RFB or
whatever), with the ability to clone the same window layout onto all
displays, or have distinct displays and move windows between them, a lot
like the way we currently deal with multiple monitors per seat. This
also solves the $DISPLAY problem rather nicely.
Regards,
S
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] User sessions, session buses, user buses
On 01/30/2015 09:30 AM, Simon McVittie wrote: Remaining issue: environment variables == […] As a short-term solution, I'm tempted to write that tool, but make it only upload a whitelisted set of variables automatically, and say if you install dbus-user-bus, you are expected to run this tool from your ~/.xsession if you need it. IMHO, env variables are something we should get rid of in the long term. It might be fine for now to provide some legacy-compatibility mechanisms (like your not-yet-written tool), but to me environment variables are something straight out of the dark ages. The long-term goal (also in a world where a graphical session is managed as a systemd user-session), the information provided until now by an environment variable should be queried dynamically by e.g. a D-Bus call to the component responsible for providing the relevant information. I know that there are huge numbers of applications/toolkits/… out there making use of environment variables for various use cases, but this shouldn't keep us from looking into the distant future where environment variables are a thing of the past. - Elias signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] User sessions, session buses, user buses
[For those who are there, I'll be at the system hackfest today and at FOSDEM this weekend, so if you are interested in these topics, please talk to me about them; I'll try to summarize discussion to these lists. For those not there, I'll try to keep up with responses via email and raise any interesting points in person.] I've recently been looking into D-Bus' interaction with X session startup, systemd --user, upstart --user, and the definition of a session. Every few months or years there is an attempt to sort out whether D-Bus has a user bus or a session bus or what. Here is another, with particular reference to systemd and potentially kdbus. Terminology === login session - A *login session* is as follows: when you log in to *dm, that starts a *graphical login session* which lasts until you log out. When you log in on a virtual console or via ssh or something, that starts a *non-graphical login session*. Background processes like cron or screen might also be non-graphical login sessions. A non-graphical login session might become graphical by running startx or similar. In a systemd-logind environment, login sessions have an ID which is made available to in-session processes in the XDG_SESSION_ID environment variable. If the Linux auditing feature is enabled, the XDG_SESSION_ID equals the audit session ID (/proc/self/sessionid). If not, there is no audit session ID, so systemd-logind makes up a sequential XDG_SESSION_ID and uses that. seat A seat is a set of displays, input devices etc. attached to a machine. Most machines have one seat seat0, which occupies all the devices. By attaching additional devices via something like http://plugable.com/products/ud-160-m you can construct a multi-seat machine. user-session I don't think there is a standard term for this so I'm making one up. The XDG_RUNTIME_DIR specification says that there is at most one XDG_RUNTIME_DIR per uid per machine, that it is created at the beginning of the user's first login session, and that it is removed at the end of a login session if no other login sessions remain for that uid. systemd-logind implements those semantics, and also runs a `systemd --user` for the lifetime of the user-session. Ubuntu previously used libpam-xdg-runtime to provide compatible semantics without systemd. The resulting situation looks something like this (assume all the sessions shown are under the same uid): \ \\ login | user- || session | \ session || - overlapping login session c42 23 | login | ||shares the user-session with 23 / session | || - 23 ends but c42 keeps u.-session c42 | ||alive \ | || - 57 begins, shares u.-sess. login | / || - c42 ends, 57 keeps user-session session | ||alive 57 | || / // no more l.sessions, u.-session ends \ \\ new l.session, u.-session starts login | user- || session | session || ... . ... .. user-sessions do not have any meaningful identifier apart from their owner's uid (strictly speaking, the owner's loginuid, i.e. the user who initially logged in, even if they su). They do not need another identifier, because by definition there is only one per uid at a time. Impact on D-Bus === There are two models for how the D-Bus session bus, which is designed to be per high-level session (whatever that means), can work in a world with user-sessions. Last time this was discussed, Havoc had the useful insight that this is not really a question about D-Bus, it's a question about how you build OSs, and in particular how you model sessions. (Up to) one high-level session per login The first model, which is how it traditionally worked (before there was such a thing as a user-session), is that each graphical login session is declared to be a session, and non-graphical login sessions are pretty much swept under the carpet and forgotten about. In graphical sessions, vaguely modern Unix OSs typically know how to start up a dbus-daemon during the creation of a graphical session (e.g. in Debian and derivatives it's started by /etc/X11/Xsession.d, and Fedora derivatives have a similar setup under a different name). If they don't, modern desktop environments also know how to start a dbus-daemon if they need one (e.g. gnome-session does this for GNOME), and if *that* doesn't start one (the I use Firefox under fvwm use-case), we have a slightly shaky but functional autolaunch mechanism based on X11 properties. In principle, a PAM module or something could ensure that we have a dbus-daemon per login session, even tty/ssh/cron login sessions (which all go through
