[systemd-devel] Rethinking getty and fast user switching

Lennart Poettering lennart at poettering.net
Mon Feb 20 08:54:36 PST 2012


On Fri, 17.02.12 16:00, Colin Guthrie (gmane at colin.guthr.ie) wrote:

> If you have your system setup for a server without a graphical display,
> you expect all (well 1 through 6 anyway) ttys to be text logins. I think
> this is uncontroversial.
> 
> Currently, if you have a graphical system, then tty1 will no longer be a
> text login, but will instead become a graphical DM login screen (let's
> discount autologin for now), but 2 through 6 will still be getty text
> logins.
> 
> If you do a graphical fast user switch this will result in a tty1 and
> tty7 being used for X instances. This is not the most intuitive for
> people switching back and forth.

What is currently implemented is more like this:

1. On systems with graphical login: tty1 is always the DM

2. On systems without graphical login: tty1 is always a getty

3. On boot, on both kinds of systems: All ttys != tty1 are unallocated

4. If via graphical fast user switching a new X sesison is oppened, the
   first unallocated tty is taken

5. If the user switches to tty2-tty6 and it is unallocated a getty will
   be spawned on it. The maximum number of ttys this happens for is
   configured in systemd-logind.conf.

6. tty1 is activated by default.

I kinda like this scheme, since we waste no resources by default,
i.e. don't start getty nor DM on any tty that wasn't in the
foreground. Also, we provide some compatibility with classic systems,
since tty2-6 are text gettys, if the user wants that, but if people use
no text gettys at all and only graphical user switching they are all
graphical logins instead.

> So, I propose the following changes:
> 
>  1. tty 1-6 is reserved for "appropriate" login agents.
>  2. tty 7-9 are reserved for text logins.

What happens if you want more than 6 parallel graphical sessions or more
than 3 parallel text logins? 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the systemd-devel mailing list