Re: GDM, getty and VTs
Josselin Mouette <joss@debian.org> writes:
> Hi,
>
> itâ??s been a long-standing tradition on Linux to have 6 started getty
> processes, in tty1 to tty6. However this doesnâ??t correspond anymore to
> the way we use our machines.
> * I donâ??t think we need more than 2 of these. They are still
> useful for servers or when some disaster happens in the GUI, but
> who opens 6 console sessions nowadays?
Right, one for startx and one to fix things if X misbehaves. :)
> * For desktop machines, the display manager starts on tty7, which
> means there is a tty switch to display it. This causes a small
> latency and can also create some bugs when youâ??re using a
> graphical boot splash.
That is hardly a problem. I think loading X and the mode switch to
high resolution takes far more time than any virtual console
switch. And console switch has to work at all times. If switching
causes bugs then find and fix the bug.
[And if you do want the display manager on tty1 then why not disable
the getty there yourself?]
> To make things worse, the latest GDM upstream version doesnâ??t include a
> tty manager anymore. Each started X server will simply use the first
> available VT. Red Hat can afford to do that because their gdm is started
> by the inittab (which is really a bad idea, but well), but in Debian
> this means it takes tty1, stomping on the getty that gets launched here
> later.
>
> So before we start adding hacks on top of the existing, maybe now is the
> time to think about how we want to use our VTs.
>
> 1/ What should be on tty1? Ideally, we should have the display manager
> here if it is started, and we should have a getty otherwise.
> * Does upstart make things like dynamic allocation of VTs
> possible?
> * Otherwise, shouldnâ??t we replace the getty processes started by
> init by a small daemon that can allocate them as we see fit?
> In all cases, as long as some consoles are managed by /etc/inittab we
> are kind of doomed.
I think getty should be first for historical reasons. I don't consider
switching to a new tty for the display manager any problem.
I also think there should never be two things on the same tty (like
getty and X) as that means one has to push the big red button to kill
the system (if one can't ssh or isn't root). Under SuSe there was a
nice DOS attack where you would keep ctrl-D pressed on a getty till
init suspended it for 5 minutes and then restart the gdm. After 5
minutes the getty came back and the X lost keyboard/mouse. Luckily
under Debian you can't get getty to restart so quickly that init
suspends it.
> 2/ How do we prevent bad interaction between console VTs and graphical
> VTs? (Of course this is closely related to question 1.)
> Given how they are done now, there will always be some race conditions
> in VT allocations without a tty manager. But as long as this code stays
> in GDM (and KDM, for that matter), we will be stuck to static allocation
> of pools of VTs prior to start anything. We can do better than that, but
> this requires system-wide allocation of VTs that could be queried from
> the display manager.
Normaly I would say we should not start getty with a fixed tty. Either
getty has to allocate one dynamically or be started with e.g. openvt.
But that conflicts with wanting getty on tty1 and tty2 at least.
I there are 2 problems here:
1) some things should use a static tty because one expects them there
2) dynamic allocation should never use a tty where something static
wants to be
One solution is simple:
- Dynamic allocation only picks free ttys.
- Static uses the tty no matter what.
So why not allocate all ttys for static use during boot, before
anything dynamic starts, and keep them allocated at all times? There
should then be a way for packages to say that they need a static tty,
e.g.
/etc/tty-helpers/<package>
being an executable (binary or script) that outputs a list of tty
numbers needed by <package>. The getty script could check the inittab
to see where gettys will run. The xorg script could check if xorg is
configured for a static tty or not and so on.
The advantage of this would be that users can easily add their own
helper too. On my xen server for example I have the consoles for the
domUs on tty3/4/5/6. So each tty is a different virtual server. I
wouldn't want GDM to take one of those if a domain happens to be shut
down for the time being.
> 3/ Even if we find a perfect solution, what do we do with legacy display
> managers? That includes GDM 2.20, which is bound to stay here for a
> while since there are other regressions. To avoid patching all of them,
> there should be a fallback mode where the DM can allocate what it wants
> starting from tty7, as it is possible now.
By reserving ttys the "next free" would automatically start from 7 (or
8).
> It is, of course, possible to integrate a tty manager in the new GDM
> codebase and just keep things as they are today, but before doing that,
> Iâ??d prefer to look for better solutions.
Would be far better to have a common "give me a tty" helper that xdm,
kdm, gdm and startx, getty? can all use. Code duplication is bad. The
above idea also does not need the code to be changed. Just adds a
little script.
> Iâ??d appreciate if people with knowledge of the init system could explain
> their ideas on the topic so that we can decide on a course of action.
>
> Thanks,
MfG
Goswin
Reply to: