I see this discussion petered out in November, but as I missed the followups after the change in subjects for the thread, I had seen only Dan Nicholson's initial attempt at rectifying this problem I've seen the philosophical discussion, but the real problem traces to the GDM version 2.20, which involved a major rewrite of the code and a regression in configurability. (Has anyone heard of MAJOR release numbers? Version 2.20 should have been 3.0, imho.) Anyhow I've extended Dan Nicholson's approach in what I think is a more reliable manner. I don't use XDM, so I can't comment on that, but I see that KDM in the standard distribution has been configured to start X on vt1 and then go up from vt7 for later sessions. Since reconfiguring KDM versus the upstart files involves multiple changes, I leave that to the experts. (See the file /etc/kde/kdm/kdmrc to see what I mean.) I leave /etc/event.d/tty1 alone and start it, if need be, when /etc/X11/prefdm kicks in. The logic in prefdm, by the way, kicks in AFTER plymouth shuts down, not before, in case it feels like re-creating the /var/spool/gdm/force-display-on-active-vt file. I also discovered that GDM removes that file each time a session ends, so I modified /etc/gdm/PostSession/Default to take that into account. This is why the first session was created on vt1 but all subsequent sessions after that user logs out were created on vt7. The basic idea of "forcing" the display on an active VT is invalid, I think. It affects only vt1, not any of the others. If Sam is working on vt2 and Julie starts a new session, do you want Sam to be kicked off entirely? No. The only issue is with vt1, which the kernel uses to write boot messages. If you do "fgconsole --next-available", you'll see that vt1 is NEVER available, and if you try "deallocvt 1" you'll see why ... "VT 1 is the console and cannot be deallocated". So the only issue is that GDM won't start X on vt1 if it thinks it's already allocated, even if there are no processes running there. "fuser -v /dev/tty1" tells us whether we *really* want to start (or continue) X there. <div>I've tested this pretty thoroughly from runlevel 5 (killing gdm-binary from within the gdm session and other weird states) and it seems to work. </div><div></div><div>The "telinit 5" situation also seems to work fine. </div> --- /etc/X11/prefdm.orig 2009-08-31 20:38:02.000000000 +0200 +++ /etc/X11/prefdm 2009-09-01 13:27:45.000000000 +0200 @@ -8,6 +8,10 @@ # Run preferred X display manager quit_arg= preferred= + +# Hack for Fedora-modified GDM +FORCEACTIVEVT=yes + if [ -f /etc/sysconfig/desktop ]; then . /etc/sysconfig/desktop if [ "$DISPLAYMANAGER" = GNOME ]; then @@ -31,6 +35,22 @@ # shut down boot splash /usr/bin/plymouth quit $quit_arg +# Tell Fedora-modified GDM to reuse VT1 if it's really inactive or if X is already there; +# otherwise, tell it not to use VT1 (and start a terminal there if need be) +TTY1_TASK=$(fuser -v /dev/tty1 2>&1|awk -v RS='' '/ / { print $9 ; exit }') +if [ -z "$preferred" ] || [ "$preferred" = /usr/sbin/gdm ]; then + if [ "$FORCEACTIVEVT" = yes ]; then + if [ -z "$TTY1_TASK" ] || [ "$TTY1_TASK" = Xorg ] || "$TTY1_TASK" = X ]; then + touch /var/spool/gdm/force-display-on-active-vt + fi + else + rm -f /var/spool/gdm/force-display-on-active-vt + if [ -z "$TTY1_TASK" ]; then + initctl start tty1 >/dev/null + fi + fi +fi + shopt -s execfail [ -n "$preferred" ] && exec $preferred "$@" >/dev/null 2>&1 </dev/null --- /etc/gdm/PostSession/Default.orig 2009-07-27 16:41:41.000000000 +0200 +++ /etc/gdm/PostSession/Default 2009-08-31 19:25:54.000000000 +0200 @@ -1,3 +1,26 @@ #!/bin/sh +PATH=/sbin:/usr/sbin:/bin:/usr/bin + +# Hack for Fedora-modified GDM +FORCEACTIVEVT=yes + +if [ -f /etc/sysconfig/desktop ]; then + . /etc/sysconfig/desktop +fi + +# Tell Fedora-modified GDM to reuse VT1 if it's really inactive or if X is already there; +# otherwise, tell it not to use VT1 (and start a terminal there if need be) +TTY1_TASK=$(fuser -v /dev/tty1 2>&1|awk -v RS='' '/ / { print $9 ; exit }') +if [ "$FORCEACTIVEVT" = yes ]; then + if [ -z "$TTY1_TASK" ] || [ "$TTY1_TASK" = Xorg ] || "$TTY1_TASK" = X ]; then + touch /var/spool/gdm/force-display-on-active-vt + fi +else + rm -f /var/spool/gdm/force-display-on-active-vt + if [ -z "$TTY1_TASK" ]; then + initctl start tty1 >/dev/null + fi +fi + exit 0 . From: "Dan Nicholson" <dbn lists gmail com><ul><li>To: "Development discussions related to Fedora" <fedora-devel-list redhat com></li> <li>Subject: Re: Reasons to preseve X on tty7</li><li>Date: Tue, 11 Nov 2008 20:05:38 -0800</li></ul> <hr> <pre>On Tue, Nov 11, 2008 at 1:28 PM, Bill Nottingham <notting redhat com> wrote: > Dan Nicholson (dbn lists gmail com) said: >> > Further testing with this is giving me some bizarre errors and hangs >> > relating to VT switching that don't happen with this patchset backed >> > out. Unless I can track those down, I can't really recommend using >> > it. >> >> Without doing anything from event.d, there's nothing on tty1 for the >> `telinit 5' from runlevel 3 case, right? I don't want you to use a >> broken patch, but I do think the current behavior is wrong. > > It's 'wrong', but it's predictably wrong without side-effects on the > rest of the interface (crash, hang, etc.) and easily explained what > to do. At this stage of the release cycle, that's better than a patch > that fixes it for some cases and does really bizarre things in ways > that I haven't characterized yet. (I've seen hangs in the VT switch > code, and I can reliably reproduce a condition where the console > is perfectly fine... but not actually updating on the screen.) > Still poking at it, though. That's understandable. It would be nice if the display manager would be taken into account since kdm and xdm users will just get nothing on tty1 in runlevel 5 at all times. I'm sure you'll come up with something sooner or later. -- Dan </pre>