[systemd-devel] [RFC] logind: introduce session "positions"

Lennart Poettering lennart at poettering.net
Tue Dec 10 15:51:21 PST 2013


On Mon, 02.12.13 14:07, David Herrmann (dh.herrmann at gmail.com) wrote:

> 
> Hi
> 
> On Mon, Dec 2, 2013 at 10:57 AM, Colin Guthrie <gmane at colin.guthr.ie> 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).

class=background sessions are not attached to seats in general.

> 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.

The current code explicitly allows multiple sessions on the same VT, to
deal with sessions that still have some processes running after the user
logged out while a new user is already logged in on the same VT. For the
position stuff we should probably support the same logic. And IIUC then
David's patch alerady covers that and makes the most recent session the
one in the foreground.

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list