Reasons to preseve X on tty7

Fri Sep 4 16:51:38 UTC 2009

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.

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.
The "telinit 5" situation also seems to work fine.

--- /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>

   - *To*: "Development discussions related to Fedora" <fedora-devel-list
   redhat com>
   - *Subject*: Re: Reasons to preseve X on tty7
   - *Date*: Tue, 11 Nov 2008 20:05:38 -0800

------------------------------

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090904/8b13d82b/attachment.htm>
