Hi On Mon, Dec 2, 2013 at 10:57 AM, Colin Guthrie <[email protected]> wrote: > 'Twas brillig, and David Herrmann at 01/12/13 11:43 did gyre and gimble: >> During session_load() or if two sessions have the same VTnr, we may end up >> with two sessions with the same position (this shouldn't happen, but lets >> be fail-safe in case some other part of the stack fails). > > I presume this would actually be quite easy if we get around to > implementing Lennart's suggested force-new-session=1 pam_systemd option > which will be used by su-l, sudo-i, and possible polkit stuff?
Not really. On seats without VTs, the new session just ends up as a new session (with it's own position or no position at all if class=="background" and we skip positions for background sessions). On seats with VTs, it really doesn't matter as SwitchTo() just results in chvt(). So behavior stays the same. You're right that on VTs we can easily end up with two sessions on a single VT. I dislike that, but apparently people want it.. You get very weird semantics then, but I'm not touching that code as I don't care. >> This case is >> dealt with gracefully by ignoring any session but the first session >> assigned to the position. Thus, session->pos is a hint, seat->positions[i] >> is the definite position-assignment. Always verify both match in case you >> need to modify them! > > Even if pam_systemd did get this new feature, it sounds like this > strategy would work fine for dealing with switching anyway. Yepp, I designed the fallback to treat duplicates as class==background. So this should be fine. Thanks David _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
