Josselin Mouette <j...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org