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 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 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). > > 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. > > However, the people doing the work have a somewhat strong correlation > with the people who want a different model, for which read on... > > Digression: (at least some) users and developers don't want that > ---------------------------------------------------------------- > > One major issue with one high-level session (and hence one session bus) > per login session is that it places an artifical barrier between login > sessions. It's difficult for cron jobs, ssh logins, tty logins to share > non-GUI backend services such as dconf, Rygel, Telepathy: on my NAS box, > which runs Rygel with no GUI to export my music in a way the > notoriously picky PS3 system software can understand, I had to > construct a D-Bus session to let Rygel and Tracker components talk > to each other. Happily, I had already written dbus-run-session(1), > but I shouldn't need to do this rubbish to let non-GUI daemons talk > to each other - it should just work. > > 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 (unless you have configured > systemd-logind to kill leftover processes, as required by the sysadmins > of computer labs and other massively multi-user machines, in which case > you don't get to run screen sessions and that's by design). > However, the login-session-centric model can't cope with that: > the dbus-daemon dies with the X server, the D-Bus services die with > the dbus-daemon, and now the duplicity(1) process in your screen session > can't use gvfs to upload your backups to a server (or whatever). > > Another issue is that it is an extremely poor match for how > `systemd --user` works (although apparently a better match for > how Ubuntu uses `upstart --user`, which I hope to discuss with Ubuntu > people at the systemd hackfest today / at FOSDEM) - you can't use > systemd to manage your login-session-bound D-Bus services, because they > all share a systemd, which doesn't know which login session wants which > service. > > I think it's telling that, in recent discussion with Ubuntu developers > about their use of one `upstart --user` per login session, they > clarified that they only actually do this for *graphical* login > sessions, and they provide tools to let a developer copy the environment > variables from what, conceptually, should be another session, > effectively "joining" that session for a subtree of processes. I think > this proves the point that Robert McQueen made on the subject back in 2006: > > "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)." > > One high-level session per user-session > --------------------------------------- > > As a result of the problems noted above, various people, most vocally > the systemd and GNOME developers, have advocated a different model > for how to model sessions in the OS - what I called "user-sessions" > above. A typical implementation of that idea forbids multiple graphical > login sessions altogether: if you type your username and password into > gdm while already logged in on another virtual console, it will just > vt-switch to your existing graphical login session and unlock it. > > 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. > > What this means for D-Bus > ------------------------- > > 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.) > > I think in practice that design will mean that by default, libdbus tries > to connect to both user-session- and login-session-centric locations for > the bus (but the "wrong one" for this OS will fail and the "right one" > will succeed), while dbus-user-bus and dbus-x11 would arrange for the > bus to listen in the appropriate place for one option or the other so > that the appropriate version succeeds. > > Conveniently, this is what I've already implemented (in two > different ways): "try the user-session-centric path first, and if that > fails, fall back to login-session-centric autolaunch". There is the > slight nit that the server side of user-session-centric operation > requires systemd, although that could be argued to be a feature: the > other reasonable implementation is libpam-xdg-runtime, which AIUI is > unmaintained now that Ubuntu has switched to systemd-logind, and the > people who are avoiding systemd on general principles (hello Devuan!) > are probably the sort of people who are sufficiently change-averse to > prefer D-Bus to work the way it worked in 2005 (if they install it at > all). I'd be willing to consider implementations that work with other > service managers if their authors are willing to help maintain them. > > The glorious(?) kdbus future > ============================ > > kdbus is a proposed Linux kernel module providing > somewhat-D-Bus-compatible message-passing semantics (I'm being vague > because it's been 4 months since I last looked at it in detail - I hope > to return to it soon). To provide complete dbus-daemon-like > functionality, you also need a user-space process to create the bus and > manage activations; the > reference implementation, and so far the only implementation, is in > systemd. > > The systemd developers who are working on the user-space counterpart > for kdbus have indicated that they have zero interest in supporting a > login-session-centric setup for session kdbus. In practice, I think > this means that the proponents of a login-session-centric world either > can't use kdbus in their sessions, or need to convince the relevant > developers that the added complexity of their model is worth it, or need > to write their own user-space for kdbus sessions and > disable systemd's. (It's not all bad - they can still use kdbus for > the system bus, which is already an improvement.) > > 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 > > 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. > > 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". > > Thoughts? Other than my two additions, I agree with Lennart. Thanks David _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
