[systemd-devel] systemd-consoled: agetty+login

[Jonathan de Boyne Pollard]

The way that you're going right now, you're going to surprise a lot of
people, possibly not pleasantly, in a little while.  You've presented this as
a replacement of agetty and login.  But the use cases of getty+login and what
you're doing are somewhat different.  People expecting to get a
systemd-consoled system that behaves the same as virtual terminals with
gettys on them are going to instead get a system that operates somewhat
differently, the way that you're going.

What you're looking at doing follows the GUI model of a single "greeter"
session that spawns other "user" sessions running systemd-consoled after the
"greeter" has completed a login dialogue.  The TUI model of VTs+gettys, even
as modified by systemd-logind, in contrast has multiple "greeter" sessions that
(conceptually) exec into "user" sessions once /bin/login has spawned a login
shell.

In other words: What people expect from the TUI system is multiple
(systemd-logind) sessions, each with an individual login dialogue, and each of
which, serially, can comprise multiple login sessions (switch to
systemd-logind session #3, log in as user A, do things in a user A login
session, log out, log in as user B, do things in a user B login session, log
out).  What you're actually going to give them instead is one single login
dialogue in a "greeter", which spawns a new (systemd-logind) session that
can only comprise a single login session.

There's nothing inherently wrong with this.  In fact I did a similar design
myself some years ago, for that non-Linux system that I mentioned.  But you
are going to surprise people who think that you're going to give them an
it-works-just-like-init+getty+login-did TUI login system.