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

David Herrmann dh.herrmann at gmail.com
Tue Dec 17 08:25:03 PST 2013


Hi

On Fri, Dec 13, 2013 at 7:20 PM, Jonathan de Boyne Pollard
<j.deboynepollard-newsgroups at ntlworld.com> wrote:
> 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.

That's not true. systemd-consoled does not care for
session-management. It expects its parent to setup the session. This
is what systemd-welcomed is for. systemd-welcomed is the greeter which
setups up everything and spawns the right session. You can run as many
of it as you want and each of them can run in single-session or
multi-session mode.

However, our default will probably be just one systemd-welcomed
greeter similar to how gdm/xdm/... work.

Thanks
David


More information about the systemd-devel mailing list