[ I'm going to trim the CC, I'm pretty sure everyone who has commented so far is on systemd-devel ]
On Wed, 2014-01-08 at 13:55 +0100, David Herrmann wrote: > This basically defeats the whole purpose of a session. A lot of it, yes. The session becomes: * A refcount on the user@.service * A claim of particular devices (tty, X server) > If you now do > session.kill(), you kill both logins. That's not intentional, I guess. No. The only process actually in the session cgroup would be a stub. Asking logind to kill it would cause it to release the fd and hence drop a ref on the user@.service. Only once all sessions are closed would the user@.service terminate. > > * If two logins (of the same user) are associated with different > > seats, this is not really supported at the moment, so we could ban it, > > or we could simply allow it and temporarily merge the two seats and > > let the session controller (window manager) deal with how that should > > be presented to the user. This would probably mean that we want > > logind's interfaces for getting hardware devices should be per-user, > > and not per-session. Yeah...this bit is tricky. For the case of GNOME where it's simply not supported to log in multiple times, all we need is a mechanism to discover the X server that gdm spawned (not as part of the session or user@.service). The way that works in my prototype patches is that GDM sets the x11-display property via PAM, and then systemd writes that to $XDG_RUNTIME_DIR. From there, libX11 can pick it up automatically. Now, for "session controllers" that want to support multiple logins, it gets far more complex. I think they'd have to do something like what you were saying with double templating (somecontroller@<num>.service). Or as I say below, these controllers just stay as they are today. > I talked to Jasper about this shortly. I really think we need to > discuss this at FOSDEM. What he said is that they try to ditch > sessions entirely and move to "user-based sessions" instead. So if you > login multiple times as the same user, you always join the same > session (or are rejected, whatever your policy is). A lot hinges on the precise meaning of "join" here. Presently, gdm will just VT-switch you to your original X server if you try to log in again. > * Multi-seat: You cannot login as the same user on two seats > simultaneously. This would require running "systemd --user" twice for > the same user. I'm not sure whether that is possible? Same requirement > would be given for the user-bus, etc.. We could use unit-templates, > something like systemd-consoled@<num>.<seat>.service. However, > multi-layer templates seem cumbersome. Or "session controllers" that want to do this simply don't run per user; they just continue to have all of their processes in the session cgroup and work just as they do today. I can't think of a problem with that. > * Session-assignment: This is the bigger problem, imho. If we run > processes as systemd --user units, these services are childs of > systemd, not of gnome-session or else. As systemd does not run in a > session, the units itself cannot inherit a session. So we really > destroy the session concept then for anything that runs for the whole > user. Yes, as I said; I think we'll all have to come to grips with the idea that a session is just a refcount on user@.service with some metadata; it no longer holds the process tree. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
