GDM, getty and VTs

[Josselin Mouette]

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?
* 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.

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.

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.

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.


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.

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,

[Samuel Thibault]

* 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?

Blind people and crazy people who always run startx by hand, and also on
servers. Actually I even sometimes need to open another one. No, even
in that case I don't necessarily want to run X. Yes, in that case gdm
doesn't get started so it shouldn't be so hard to find a solution.

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

The graphical boot splash could go to tty7.

* 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 guess you mean as long as there is no negociation between gdm and
whatever decides where gettys go?

Samuel

[Josselin Mouette]

Post by Samuel Thibault

Post by Josselin Mouette
* 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 guess you mean as long as there is no negociation between gdm and
whatever decides where gettys go?

GDM does try to use a VT that is not currently in use - although there
can be race conditions. The process which doesn’t negociate is init:
consoles defined in /etc/inittab are started without any thought,
regardless of whether they are available or not.

[Bernhard R. Link]

Post by Josselin Mouette

Post by Samuel Thibault
I guess you mean as long as there is no negociation between gdm and
whatever decides where gettys go?

GDM does try to use a VT that is not currently in use - although there
can be race conditions.

So gdm does not negotiate but just claims "first!".

Getting things at random places is also the opposite of being nice to
users. ("Now switch back to graphic by pressing Alt-F7". "Does not
work". "Are you sure you did, try again". "only black screen". "oh, try
Alt-F8 then"...).

Post by Josselin Mouette
consoles defined in /etc/inittab are started without any thought,
regardless of whether they are available or not.

Actually init has nothing to do with consoles. It does not start
consoles but programs, one one of those is getty. And while having
no "some other program is buggy and used the tty I am supposed to use"
warning is annoying, not having your consoles because something breaks
and the system thinks they are still in use would be even worse.

Bernhard R. Link

P.S:
That said, reducing text consoles running might be a sensible thing.
(Even I stopped to reconfigure every installed computer to have 8
instead only 6 getties since about a release). But arguing it is
necessary because a bug in gdm should not cause bugy behaviour, is ...

[Josselin Mouette]

Post by Bernhard R. Link

Post by Josselin Mouette

Post by Samuel Thibault
I guess you mean as long as there is no negociation between gdm and
whatever decides where gettys go?

GDM does try to use a VT that is not currently in use - although there
can be race conditions.

So gdm does not negotiate but just claims "first!".

What else can it do? It has to manage its VTs for itself. Currently it
is simply forced to use the ones starting from tty7, but it is arbitrary
and inconsistent.

Post by Bernhard R. Link
Actually init has nothing to do with consoles. It does not start
consoles but programs, one one of those is getty. And while having
no "some other program is buggy and used the tty I am supposed to use"
warning is annoying, not having your consoles because something breaks
and the system thinks they are still in use would be even worse.

I’m not sure it is best fixed in init itself (which is why I’m asking
about upstart’s capabilities). But in all cases I think we’d be better
if text consoles could be dynamically allocated just like graphical
ones.

Post by Bernhard R. Link
That said, reducing text consoles running might be a sensible thing.
(Even I stopped to reconfigure every installed computer to have 8
instead only 6 getties since about a release). But arguing it is
necessary because a bug in gdm should not cause bugy behaviour, is ...

You are just trolling. I precisely want to fix the bug in GDM the
correct way - and I don’t think re-introducing a VT manager in GDM
itself is the best solution.

[Bernhard R. Link]

Post by Josselin Mouette

Post by Bernhard R. Link
So gdm does not negotiate but just claims "first!".

What else can it do? It has to manage its VTs for itself. Currently it
is simply forced to use the ones starting from tty7, but it is arbitrary
and inconsistent.

There are those things called 'configuration files'.
Adding one (or extending an existing one) in which one can
configure what ttys to use (or rather which not to use) makes the
problem go away.

Bernhard R. Link

[Josselin Mouette]

Post by Bernhard R. Link

Post by Josselin Mouette

Post by Bernhard R. Link
So gdm does not negotiate but just claims "first!".

What else can it do? It has to manage its VTs for itself. Currently it
is simply forced to use the ones starting from tty7, but it is arbitrary
and inconsistent.

There are those things called 'configuration files'.
Adding one (or extending an existing one) in which one can
configure what ttys to use (or rather which not to use) makes the
problem go away.

No, it keeps the problem as it is today.

[Giacomo A. Catenazzi]

Post by Josselin Mouette

Post by Bernhard R. Link

Post by Josselin Mouette

Post by Samuel Thibault
I guess you mean as long as there is no negociation between gdm and
whatever decides where gettys go?

GDM does try to use a VT that is not currently in use - although there
can be race conditions.

So gdm does not negotiate but just claims "first!".

What else can it do? It has to manage its VTs for itself. Currently it
is simply forced to use the ones starting from tty7, but it is arbitrary
and inconsistent.

Inconsistent? The people who cares known about Alt-F7. Any change
will make it inconsistent.

Arbitrary? Yes, like "$" on key four.

Main display should have a constant tty (on normal configuration).
[x crashed, we must be able to tell our user how to restore most
of the system in a easy way]

If you think it is so important to move tty, please check what is
gnome and what is gnome independent, so if possible, provide a
generic program or library that do the right thing for all
Debian (not just for GNOME). Otherwise, please provide patch
for the main xdm (and clones), to have a consistent behaviour.

ciao
cate

[Goswin von Brederlow]

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

[Kurt Roeckx]

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?

I still have 12 console sessions open, and use screen to have
more of them.


Kurt

[Christian Perrier]

Post by Kurt Roeckx

* 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?

I still have 12 console sessions open, and use screen to have
more of them.

I hardly think this is Joe Random User's setup..:-)

Not considering the technical backgorund (which is of course an easy
stance), it could be really interesting to have *by default* the
default X session on tty1, when a display manager is used, and
something like 2 other console sessions on tty2 and tty3.

Of course, if no *dm is used, then the system should logically default
to N consoles with the first one on tty1. I'd say that N should, in
such case, be greater than 2.

[Thilo Six]

Hello

Christian Perrier wrote the following on 15.11.2009 07:13

Post by Christian Perrier

Post by Kurt Roeckx

* 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?

I still have 12 console sessions open, and use screen to have
more of them.

I hardly think this is Joe Random User's setup..:-)
Not considering the technical backgorund (which is of course an easy
stance), it could be really interesting to have *by default* the
default X session on tty1, when a display manager is used, and
something like 2 other console sessions on tty2 and tty3.

That would break *all* "How to fix my broken X11" on the net. Really bad
especial for those who need them most - newbees.
ALT-CTRL-F7 is somewhat of a standard.

Post by Christian Perrier
Of course, if no *dm is used, then the system should logically default
to N consoles with the first one on tty1. I'd say that N should, in
such case, be greater than 2.

$ grep "ACTIVE_CONSOLES" /etc/default/console-setup
ACTIVE_CONSOLES="/dev/tty[1-6]"

I really wonder what else is needed then this? As long as this setting isn't
going to be overwritten by some other software i fine it all.
--
bye Thilo

4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F

[Julien Cristau]

Post by Thilo Six
Christian Perrier wrote the following on 15.11.2009 07:13

Post by Christian Perrier
Not considering the technical backgorund (which is of course an easy
stance), it could be really interesting to have *by default* the
default X session on tty1, when a display manager is used, and
something like 2 other console sessions on tty2 and tty3.

That would break *all* "How to fix my broken X11" on the net. Really bad
especial for those who need them most - newbees.
ALT-CTRL-F7 is somewhat of a standard.

It's already broken on fedora, at least. So if it's a standard, it's a
dying one.

Cheers,
Julien

[Ben Hutchings]

Post by Julien Cristau

Post by Thilo Six
Christian Perrier wrote the following on 15.11.2009 07:13

Post by Christian Perrier
Not considering the technical backgorund (which is of course an easy
stance), it could be really interesting to have *by default* the
default X session on tty1, when a display manager is used, and
something like 2 other console sessions on tty2 and tty3.

That would break *all* "How to fix my broken X11" on the net. Really bad
especial for those who need them most - newbees.
ALT-CTRL-F7 is somewhat of a standard.

It's already broken on fedora, at least. So if it's a standard, it's a
dying one.

If Fedora jumps off a cliff (I wouldn't put it past them ;-) should we
do it?

Ben.

[Michael Banck]

Post by Ben Hutchings
If Fedora jumps off a cliff (I wouldn't put it past them ;-) should we
do it?

No, but what does this have to do with the current thread?


Michael

[Andrei Popescu]

Post by Christian Perrier
Not considering the technical backgorund (which is of course an easy
stance), it could be really interesting to have *by default* the
default X session on tty1, when a display manager is used, and
something like 2 other console sessions on tty2 and tty3.

Please don't forget about the switch user functionality which creates a
new X session (by default on tty8). I think it would make sense to keep
the X sessions "adjacent".

Regards,
Andrei

[Luca Bruno]

Hello,
I think the problem only happens for desktop startup.

Say you _don't_ start X at boot, this is what happens:
- 6 ttys are occupied
- startx will use the next free tty7, which is what I expect if I don't
specify vt to X.
In this case dynamic allocation is good.

Say instead you have *dm at startup: I think in this case dynamic allocation
is not good, because it means X could be started on vt1, vt2, ... Actually
on vt2.

This is my proposal: I'd say to start X in a fixed tty _only_ when X is started
at boot, in all other cases the tty will be chosen dynamically as next free
or by whatelse policy.
Of course, if the fixed tty is already in use, then it will use the next
free; but that's not our case I think.
The problem is: how to use a fixed-configurable tty "only at boot time"?

I think this is the best compromise. I don't know if my English was clear
enough.

Best regards,

[Steve Langasek]

Post by Christian Perrier
Of course, if no *dm is used, then the system should logically default
to N consoles with the first one on tty1. I'd say that N should, in
such case, be greater than 2.

This adds much more complexity to the getty configuration than is otherwise
necessary, because we also want to make sure that if no DM is configured,
the tty that's up by default at boot time has a login prompt on it. I don't
think this complexity is warranted; I think it's much more straightforward
to just make sure tty1 is always a getty, and always open X on tty7, in the
default config.

(I consider it a failure of the gdm upstream rewrite that the code no longer
implements support for this; but really, that's just one of many regressions
in functionality from the new upstream version of gdm...)

[Michael Goetze]

Hi,

Post by Josselin Mouette
* Does upstart make things like dynamic allocation of VTs
possible?

Upstart doesn't do anything special WRT to VTs. You can constantly
respawn a getty on /dev/tty3, or you can constantly respawn openvt
getty, or you can run a script once saying "assign me a VT" and then
spawn and respawn getty on that VT.

Regards,
Michael

[Gabor Gombas]

Post by Josselin Mouette
* 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.

Is that still true with KMS and framebuffer console? IMHO if the boot
splash and gdm both use the same mode, then KMS can avoid re-programming
the card on a VT switch, thus the latency goes away.

Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------

[Harald Braumann]

On Sat, 14 Nov 2009 15:45:11 +0100

Post by Josselin Mouette
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?

I do. And if people don't use them, there's still no harm done.

Post by Josselin Mouette
* For desktop machines, the display manager starts on tty7,
which means there is a tty switch to display it. This causes a small
latency

I think the latency comes from the switch from text mode to graphical
mode, which should be alleviated by KMS.

Post by Josselin Mouette
and can also create some bugs when you’re using a
graphical boot splash.

Which bugs?

Post by Josselin Mouette
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,

Why?

Post by Josselin Mouette
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.

What's the actual problem with that?

Post by Josselin Mouette
We can do better
than that, but this requires system-wide allocation of VTs that could
be queried from the display manager.

What's the use-case for that?

I don't see any real arguments against the set-up as it is now or for a
new way to do it. Just because GDM is broken doesn't mean we should
change a system that is, in your own words, a long-standing
tradition. I see no gain at all in that but instead it seems it would
make the system more complex, harder to understand and confuse users.

Cheers,
harry

[Josselin Mouette]

Post by Harald Braumann
I don't see any real arguments against the set-up as it is now or for a
new way to do it.

There are no real arguments for keeping the current setup either.

Post by Harald Braumann
Just because GDM is broken doesn't mean we should
change a system that is, in your own words, a long-standing
tradition.

Just because it is a tradition doesn’t mean it’s the correct way.
Actually, several people in this thread felt the current way is better,
while explaining they don’t have *enough* text VTs for their personal
use in the default setup.

Let me sum up the situation otherwise:
* Current situation is far from perfect.
* New GDM upstream, as is, is completely broken.
* Fedora solution (start the DM by inittab, without any kind of VT
allocation at all) is out of question.
* Ubuntu solution (big ugly hack to hardcode tty7 but only for the
first X server started) is out of question.

So we need to write quite come code to fix GDM anyway, and I’d like to
use this opportunity to come up with a better solution than what we have
now, instead of doing this work just to come back to the current
situation.


Let me explain what proposal I have in mind after reading the thread,
now. It might sound a little crazy but I think it would be much better
than just keeping our current setup.

We remove entirely the getty respawning from /etc/inittab. Instead, a
new daemon is started by a regular init script. This daemon does the
following:
* Opens all /dev/tty1 to tty6 and display a d-i-like “press enter
to activate this console” in them.
* Provide a very simple interface to reserve a VT, that can be
queried by the display manager.
* Whenever you press enter on a VT, reserve it and start a getty
process.
* When almost all ttys are allocated, start opening tty7+ and so
on.
* If no display manager is started, always run a getty process in
tty1.

I don’t see this as rocket science software, and it means:
* No useless getty processes are started.
* tty1 is always the first VT you log on, regardless of your
setup.
* You can start an arbitrary number of text or graphical consoles,
without any configuration.

Cheers,

[Samuel Thibault]

* Opens all /dev/tty1 to tty6 and display a d-i-like “press enter
to activate this console” in them.
* Provide a very simple interface to reserve a VT, that can be
queried by the display manager.

And that reservation would kill the Open above? (else you still have a
conflict)

Samuel

[Josselin Mouette]

Post by Samuel Thibault

Post by Josselin Mouette
* Opens all /dev/tty1 to tty6 and display a d-i-like “press enter
to activate this console” in them.
* Provide a very simple interface to reserve a VT, that can be
queried by the display manager.

And that reservation would kill the Open above? (else you still have a
conflict)

Yes of course. (There are probably several such details to iron out, I’m
still in the “write ideas” phase.)

[Harald Braumann]

On Mon, 16 Nov 2009 11:07:52 +0100

Post by Josselin Mouette

Post by Harald Braumann
I don't see any real arguments against the set-up as it is now or
for a new way to do it.

There are no real arguments for keeping the current setup either.

Yes there is: that it has been like this forever. This is a value of
its own, because users expect it to be like this and rely on it.
Changing it will confuse many. It doesn't mean that it is carved in
stone, but there should be good reasons and the gain should outweigh
the cost.

Post by Josselin Mouette

Post by Harald Braumann
Just because GDM is broken doesn't mean we should
change a system that is, in your own words, a long-standing
tradition.

Just because it is a tradition doesn’t mean it’s the correct way.

So far I haven't seen any argument as to why it shouldn't be the correct
way.

Post by Josselin Mouette
Actually, several people in this thread felt the current way is
better, while explaining they don’t have *enough* text VTs for their
personal use in the default setup.
* Current situation is far from perfect.

Why?

Post by Josselin Mouette
* New GDM upstream, as is, is completely broken.

That seems to be the only reason. But this is clearly a bug in GDM,
that should be fixed there.

Post by Josselin Mouette
Let me explain what proposal I have in mind after reading the thread,
now. It might sound a little crazy but I think it would be much better
than just keeping our current setup.
We remove entirely the getty respawning from /etc/inittab. Instead, a
new daemon is started by a regular init script. This daemon does the
* Opens all /dev/tty1 to tty6 and display a d-i-like “press
enter to activate this console” in them.
* Provide a very simple interface to reserve a VT, that can be
queried by the display manager.
* Whenever you press enter on a VT, reserve it and start a getty
process.
* When almost all ttys are allocated, start opening tty7+ and so
on.
* If no display manager is started, always run a getty process
in tty1.

To me, this seems like a solution looking for a problem. What use-case
do you have in mind here?

On my system it currently works like this:
- start gettys in /etc/inittab
- define X's tty in /etc/X11/xdm/Xservers

If you want X on another tty, change it in /etc/X11/xdm/Xservers. If you
need more ttys, add gettys to /etc/inittab. This system is so simple and
flexible, that I don't see how you can improve on it.

So the solution is to make GDM configurable by a parameter or a config
file to set the vt it should start on.

Post by Josselin Mouette
* No useless getty processes are started.

I never considered this to be a real problem.

Post by Josselin Mouette
* tty1 is always the first VT you log on, regardless of your
setup.

I don't see this as an improvement. I always want X on the same tty, no
matter in which order I do things. Or did I misunderstand something
here?

Post by Josselin Mouette
* You can start an arbitrary number of text or graphical
consoles, without any configuration.

Is this really a requirement? Where are the wishlist bugs of users
demanding this? And anyway, a simple script that looks for the next
free tty and spawns getty there solves this nice and easy.

Cheers,
harry

[Josselin Mouette]

Post by Harald Braumann

Post by Josselin Mouette
Just because it is a tradition doesn’t mean it’s the correct way.

So far I haven't seen any argument as to why it shouldn't be the correct
way.

It’s broken because:
* there are race conditions in the way VTs are allocated;
* text consoles are statically allocated, which means there are
too many for some users and not enough for some others;
* the display manager should run on the first VT.

Post by Harald Braumann

Post by Josselin Mouette
* New GDM upstream, as is, is completely broken.

That seems to be the only reason. But this is clearly a bug in GDM,
that should be fixed there.

Yes, but there are better ways to fix bugs than mimicking already
existing bugs.

Post by Harald Braumann
If you want X on another tty, change it in /etc/X11/xdm/Xservers. If you
need more ttys, add gettys to /etc/inittab. This system is so simple and
flexible, that I don't see how you can improve on it.

Yeah, sure. Like, you know, dynamic VT allocation and X server.

Post by Harald Braumann
So the solution is to make GDM configurable by a parameter or a config
file to set the vt it should start on.

You really don’t know what you are talking about, do you?

Post by Harald Braumann

Post by Josselin Mouette
* No useless getty processes are started.

I never considered this to be a real problem.

I always consider it a problem when there are unneeded processes on the
system.

Post by Harald Braumann

Post by Josselin Mouette
* tty1 is always the first VT you log on, regardless of your
setup.

I don't see this as an improvement. I always want X on the same tty, no
matter in which order I do things. Or did I misunderstand something
here?

X is not always on the same tty. It is only if you use an antiquity like
xdm. Even with startx, tty allocation is dynamic.

Post by Harald Braumann

Post by Josselin Mouette
* You can start an arbitrary number of text or graphical
consoles, without any configuration.

Is this really a requirement? Where are the wishlist bugs of users
demanding this? And anyway, a simple script that looks for the next
free tty and spawns getty there solves this nice and easy.

No it does not. Especially since “looking for the next free tty” is not
a safe operation.

Cheers,

[Harald Braumann]

On Mon, 16 Nov 2009 14:39:06 +0100

Post by Josselin Mouette

Post by Harald Braumann

Post by Josselin Mouette
Just because it is a tradition doesn’t mean it’s the correct way.

So far I haven't seen any argument as to why it shouldn't be the
correct way.

* there are race conditions in the way VTs are allocated;

Not if they're allocated statically.

Post by Josselin Mouette
* text consoles are statically allocated, which means there are
too many for some users and not enough for some others;

That's easily configurable.

Post by Josselin Mouette
* the display manager should run on the first VT.

You keep suggesting this, but I don't agree.

Post by Josselin Mouette

Post by Harald Braumann

Post by Josselin Mouette
* New GDM upstream, as is, is completely broken.

That seems to be the only reason. But this is clearly a bug in GDM,
that should be fixed there.

Yes, but there are better ways to fix bugs than mimicking already
existing bugs.

Post by Harald Braumann
If you want X on another tty, change it in /etc/X11/xdm/Xservers.
If you need more ttys, add gettys to /etc/inittab. This system is
so simple and flexible, that I don't see how you can improve on it.

Yeah, sure. Like, you know, dynamic VT allocation and X server.

Post by Harald Braumann
So the solution is to make GDM configurable by a parameter or a
config file to set the vt it should start on.

You really don’t know what you are talking about, do you?

Well, maybe not, but that's because so far I haven't had nor heard of
any problems with the current system and you refuse to explain what the
real problem is. But I start to suspect that it might have to do with
multiple X servers being started dynamically. If that's the case, and
it does make problems, than that might very well be a reason that's
more important than tradition (though I would prefer a solution that
conserves tradition).

Post by Josselin Mouette

Post by Harald Braumann

Post by Josselin Mouette
* No useless getty processes are started.

I never considered this to be a real problem.

I always consider it a problem when there are unneeded processes on
the system.

I consider a tty-management-daemon an unneeded process

Post by Josselin Mouette

Post by Harald Braumann

Post by Josselin Mouette
* tty1 is always the first VT you log on, regardless of your
setup.

I don't see this as an improvement. I always want X on the same
tty, no matter in which order I do things. Or did I misunderstand
something here?

X is not always on the same tty. It is only if you use an antiquity
like xdm. Even with startx, tty allocation is dynamic.

Thanks to that antiquity, I will be able also in the future to have X
on vt7. And I don't have to run gconf (speaking of unneeded processes).

Post by Josselin Mouette

Post by Harald Braumann

Post by Josselin Mouette
* You can start an arbitrary number of text or graphical
consoles, without any configuration.

Is this really a requirement? Where are the wishlist bugs of users
demanding this? And anyway, a simple script that looks for the next
free tty and spawns getty there solves this nice and easy.

No it does not. Especially since “looking for the next free tty” is
not a safe operation.

Fair enough. It's just that I never felt the urge to allocate vts
dynamically.

Cheers,
harry

[Goswin von Brederlow]

Post by Josselin Mouette

Post by Harald Braumann

Just because it is a tradition doesn’t mean it’s the correct way.

So far I haven't seen any argument as to why it shouldn't be the correct
way.

* there are race conditions in the way VTs are allocated;
* text consoles are statically allocated, which means there are
too many for some users and not enough for some others;

They are statically used without regards for allocation. Meaning if
anything allocates the tty first then the static getty just steals it
leaving the system seemingly frozen.

Post by Josselin Mouette
* the display manager should run on the first VT.

Post by Harald Braumann

* New GDM upstream, as is, is completely broken.

That seems to be the only reason. But this is clearly a bug in GDM,
that should be fixed there.

Yes, but there are better ways to fix bugs than mimicking already
existing bugs.

Post by Harald Braumann
If you want X on another tty, change it in /etc/X11/xdm/Xservers. If you
need more ttys, add gettys to /etc/inittab. This system is so simple and
flexible, that I don't see how you can improve on it.

Yeah, sure. Like, you know, dynamic VT allocation and X server.

Post by Harald Braumann
So the solution is to make GDM configurable by a parameter or a config
file to set the vt it should start on.

You really don’t know what you are talking about, do you?

Post by Harald Braumann

* No useless getty processes are started.

I never considered this to be a real problem.

I always consider it a problem when there are unneeded processes on the
system.

Post by Harald Braumann

* tty1 is always the first VT you log on, regardless of your
setup.

I don't see this as an improvement. I always want X on the same tty, no
matter in which order I do things. Or did I misunderstand something
here?

X is not always on the same tty. It is only if you use an antiquity like
xdm. Even with startx, tty allocation is dynamic.

Post by Harald Braumann

* You can start an arbitrary number of text or graphical
consoles, without any configuration.

How would the "Please press return to get a login" process know when
something else (like an X session) wants the tty?

Post by Josselin Mouette

Post by Harald Braumann
Is this really a requirement? Where are the wishlist bugs of users
demanding this? And anyway, a simple script that looks for the next
free tty and spawns getty there solves this nice and easy.

No it does not. Especially since “looking for the next free tty” is not
a safe operation.

Why not? What other than the getties break it?

Post by Josselin Mouette
Cheers,

MfG
Goswin

[Travis Crump]

Post by Josselin Mouette

Post by Harald Braumann

Just because it is a tradition doesn’t mean it’s the correct way.

So far I haven't seen any argument as to why it shouldn't be the correct
way.

* there are race conditions in the way VTs are allocated;
* text consoles are statically allocated, which means there are
too many for some users and not enough for some others;
* the display manager should run on the first VT.

Stupid user viewpoint. There is an order to the VTs? I always thought
it was just a 1:1 mapping from the F# keys to tty#. I've never used
tty1. My first console session is always tty3, then tty4, then tty2,
and I don't generally go beyond that. Also note that when GDM is
brought up, it never mentions which tty[that I've noticed I could be
wrong certainly once you are logged in there is no indication] it is on
so if it started on the 'first available' you would have no idea how to
get back to it if you leave it except randomly guessing. So there is a
value in knowing where it will be. If it were to randomly shift to tty1
that would strike as change for the sake of change. I suppose I would
eventually grow used to it, but what's the point?

Post by Josselin Mouette
X is not always on the same tty. It is only if you use an antiquity like
xdm. Even with startx, tty allocation is dynamic.

Occasionally X gets on a different tty after it has crashed or
occasionally even after it has been restarted. In the past I have
literally rebooted the computer to fix this problem...

Travis

[Frans Pop]

Post by Josselin Mouette
We remove entirely the getty respawning from /etc/inittab. Instead, a
new daemon is started by a regular init script. This daemon does the
* Opens all /dev/tty1 to tty6 and display a d-i-like “press enter
to activate this console” in them.
* Provide a very simple interface to reserve a VT, that can be
queried by the display manager.
* Whenever you press enter on a VT, reserve it and start a getty
process.
* When almost all ttys are allocated, start opening tty7+ and so
on.
* If no display manager is started, always run a getty process in
tty1.

How would gettys on serial (and equivalent) ports be handled in this
proposal?

Cheers,
FJP

[Josselin Mouette]

Post by Frans Pop
How would gettys on serial (and equivalent) ports be handled in this
proposal?

Good question. I guess they could be handled like the first text VTs:
ready to be started by pressing enter, on a configurable list
of /dev/ttyS? devices.

[Fabian Greffrath]

Post by Josselin Mouette
ready to be started by pressing enter, on a configurable list
of /dev/ttyS? devices.

How about the following idea:

Introduce a configuration directory (e.g. /etc/inittab.d) in which
packages can drop files to claim for allocation of specific ttys. For
example, util-linux could drop a file in this directory that claims "I
want getty on tty1-6, priority 100" whereas the gdm package could drop
a file that claims "I want the first unallocated tty, preferably tty7,
priority 110". I still don't have an idea for the actual syntax (or
even implementation) of such configuration files, but it should be
easy to adopt them to the user's individual needs.

I am not an expert and this is just a craze idea, but what do you
think about it?
--
Dipl.-Phys. Fabian Greffrath

Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum

Telefon: +49 (0)234 / 32-26334
Fax: +49 (0)234 / 32-14227
E-Mail: ***@leat.ruhr-uni-bochum.de

[Goswin von Brederlow]

Post by Fabian Greffrath

Post by Josselin Mouette
ready to be started by pressing enter, on a configurable list
of /dev/ttyS? devices.

Introduce a configuration directory (e.g. /etc/inittab.d) in which
packages can drop files to claim for allocation of specific ttys. For
example, util-linux could drop a file in this directory that claims "I
want getty on tty1-6, priority 100" whereas the gdm package could drop
a file that claims "I want the first unallocated tty, preferably tty7,
priority 110". I still don't have an idea for the actual syntax (or
even implementation) of such configuration files, but it should be
easy to adopt them to the user's individual needs.
I am not an expert and this is just a craze idea, but what do you
think about it?

I think you didn't read my previous mail.

MfG
Goswin

[Fabian Greffrath]

Post by Josselin Mouette
* Current situation is far from perfect.
* New GDM upstream, as is, is completely broken.

Would it be possible to just stick with GDM 2.20 and maintain it as a
fork (just as you do until now)?
--
Dipl.-Phys. Fabian Greffrath

Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum

Telefon: +49 (0)234 / 32-26334
Fax: +49 (0)234 / 32-14227
E-Mail: ***@leat.ruhr-uni-bochum.de

[Josselin Mouette]

Post by Fabian Greffrath

Post by Josselin Mouette
* Current situation is far from perfect.
* New GDM upstream, as is, is completely broken.

Would it be possible to just stick with GDM 2.20 and maintain it as a
fork (just as you do until now)?

It’s very likely that GDM 2.20 will be the default for squeeze, but we’d
like to ship both. But it will not be possible to keep the old codebase
for too long either.

But again, GDM being broken is just the occasion here; it is possible to
make 2.28 behave like 2.20 with enough patching.

Cheers,

[Matthew Johnson]

Post by Josselin Mouette
We remove entirely the getty respawning from /etc/inittab. Instead, a
new daemon is started by a regular init script. This daemon does the
* Opens all /dev/tty1 to tty6 and display a d-i-like “press enter
to activate this console” in them.
* Provide a very simple interface to reserve a VT, that can be
queried by the display manager.
* Whenever you press enter on a VT, reserve it and start a getty
process.
* When almost all ttys are allocated, start opening tty7+ and so
on.
* If no display manager is started, always run a getty process in
tty1.

How about a hybrid of the two? This daemon ensures that nothing which
dynamically selects ttys can allocate on 1--6 and starts a getty on them
if you press enter. Thus, If you start X or some *dm you get allocated
on the 'next free' tty (but not 1--6), people needing more VTs also get
them allocated from 7 and in the 'default' setup (one *dm and no 'extra'
ttys) alt-ctrl-f7 still works.

I don't really see any reason for users of graphical logins to care
which VT it is on most of the time.

Matt

[Gabor Gombas]

Post by Josselin Mouette
We remove entirely the getty respawning from /etc/inittab. Instead, a
new daemon is started by a regular init script. This daemon does the
* Opens all /dev/tty1 to tty6 and display a d-i-like “press enter
to activate this console” in them.
* Provide a very simple interface to reserve a VT, that can be
queried by the display manager.
* Whenever you press enter on a VT, reserve it and start a getty
process.
* When almost all ttys are allocated, start opening tty7+ and so
on.
* If no display manager is started, always run a getty process in
tty1.

If you always send a service name in a VT reservation request, then the
daemon can implement policy based on the service name, like "always
assign VTs starting from 7 for gdm". That would allow people to continue
using their existing VT allocation scheme (I'm running the X server on
vt24 for example), while the default config can be debated separately.

Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------

[Klaus Ethgen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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.

Yes. I think so.

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.

That will be a bug in my eyes.

One of the first thing I do on a new installed debian host is to disable
getty on tty1 as I will always have the last log messages on that tty
and no way to wipe it while logging in. The other ttys (2-6) are changed
to use mingetty and I am happy quite often to have it at all as I refuse
logging in as root with X. (And I think everybody logging in into X as
root should get punishment at all. I know that the RedHat people do so
but I am not RedHat and we aren't ;-)

However, please do not refer so often to RedHat, that is just an other
distribution. The last shitty thing I remember percolating to debian was
that .localdomain problem which was completely unrelated to the problem
but made many problems.

Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.de/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <***@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQEUAwUBSwEp2Z+OKpjRpO3lAQoVkgf3frjvO2XCqNMHOk55vG0Vp8DLEnRC6oIC
Sr90EHCd5sRkn3yFWw4CCoKj8exPFjFQcftI0spbxLtFeDkCSBTE+idy372Ab09E
rcsZMUGC/xCdCuqvoOmYjkVFD0FiK9Y0fNx78ZiKCKSiBIUv2KaaL2Xh7lCqimz4
oZ0TVA5Ew/ijn1RF8GkO7PLx1h1wg/zz4Yy9DSw2+uRYO/4GulDf3XH/x8+Y6z4r
xqwvFFyNZKllrQPuwAP3h2mSl5bEuagQvxrfD60UmO4UptUNuAAQc4paGH0EpwA4
9RkO2AaHLjvv53DvFb8tCENVsMuNixYG0iJGNgSO3vCZAUHSLXqs
=be0L
-----END PGP SIGNATURE-----

[Jon Dowland]

What I would like to see is something like the following.
I've no idea whether it is achievable technically, but I'd
be interested to know what others thought.

* the display manager gets the first VT. If there is no
display manager configured, a TTY is assigned instead.
(really, in the absence of an [xkg]dm, a TTY is treated
as a display manager).
* a localized process which prints "press enter to start a
console" (similar to what is present in d-i) sits on the
next available VT
* when a user hits enter, a tty is spawned, and another
instance of the "press enter" process is also spawned, and
allocated to the next available VT
* when a user logs out of a TTY, a VT switch occurs to the
previous VT [1]
* for one release cycle, I would statically allocate a
localized message to VT7, indicating the changed behaviour

The rationale behind this is - broadly - at any time you
have precicely as many TTYs as you have requested, and a
single "press enter for another TTY" process. Those who
want to use 6 VTs can spawn 6 with just one keystroke more
than the current situation. Those who never use any only
have a single "press enter" process hanging around. Those
that want lots more can create lots more.

[1] I'm not convinced this, as I've detailed it, would work
too well. What I am aiming for is a situation where you
have a list of allocated VTs, and VTs in the middle of
the list are removed when not needed. But just switching
back one VT won't achieve this, you would still have a
dead VT sitting between two actives ones if you cycled
using the arrow keys, for example, so VT "shuffling"
would need to take place, or VT navigation would need to
be redesigned around a dynamic list, rather than static
slots.

[Samuel Thibault]

I believe it would be useful to be able to configure preallocated VTs.
I know a few people whose first action at boot is starting something
like a monitoring application on VT6, dynamic allocation would break
this habit.

Samuel

[Andrei Popescu]

Post by Jon Dowland
What I would like to see is something like the following.
I've no idea whether it is achievable technically, but I'd
be interested to know what others thought.
* the display manager gets the first VT. If there is no
display manager configured, a TTY is assigned instead.
(really, in the absence of an [xkg]dm, a TTY is treated
as a display manager).

[...]

Post by Jon Dowland
* for one release cycle, I would statically allocate a
localized message to VT7, indicating the changed behaviour

Where should a second (and third, fourth...) X instance reside, one
created by the switch-user functionality for example?

Regards,
Andrei

[Mario Lang]

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?

I do, and I suspect that some blind users have a similar habit.
The point here is that X11 is really not stable enough for us to be
useful on a daily basis (at least that is my experience). I still prefer
virtual terminals over any sort of X11 based terminal, if its not
for stability its for speed. X11 terminals are noticeably more sluggish
than real virtual consoles, and the overhead involved in screen reading
is just ridiculous.

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.

[...]

2/ How do we prevent bad interaction between console VTs and graphical
VTs? (Of course this is closely related to question 1.)

I think graphical environments shouldn't start ignoring the existance of
VTs.
It certainly feels that way to me upon reading your description.

<rant>
VTs have been around longer than X11, why do people have to forcefully
break things which perfectly worked in the past?

I think it is a misunderstanding to conclude that VTs are really
not useful anymore. Linux has always been about choice (to me at
least), something I start to miss in recent years.
</rant>
--
CYa,
⡍⠁⠗⠊⠕ | Debian Developer <URL:http://debian.org/>
.''`. | Get my public key via finger mlang/***@db.debian.org
: :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
`. `'
`- <URL:http://delysid.org/> <URL:http://www.staff.tugraz.at/mlang/>

[Mike Hommey]

Ice

Weasel won't run many web pages as well as it does in Windows Firefox,
including my Linksys router's configuration page,

Iceweasel will run everything Firefox on Windows will, excepting
things where the problem is Linux versus Windows. It might help if
you changed the user agent string (in about:config) from Iceweasel
to Firefox. That makes a lot of websites work better.

Note that is not necessary since version 3.5.5-1.

Mike

[Mark Allums]

On 12/27/2009 12:21 AM, Gaijin wrote:
Ice

Weasel won't run many web pages as well as it does in Windows Firefox,
including my Linksys router's configuration page,

Iceweasel will run everything Firefox on Windows will, excepting things
where the problem is Linux versus Windows. It might help if you changed
the user agent string (in about:config) from Iceweasel to Firefox. That
makes a lot of websites work better.

Also, you might give Google Chrome a try.



Mark Allums