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

David Herrmann dh.herrmann at gmail.com
Mon Dec 2 05:07:04 PST 2013


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

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


More information about the systemd-devel mailing list