Bug 504574 - gdm respawns in tty7 after a "init1 init5"
gdm respawns in tty7 after a "init1 init5"
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: jmccann
Fedora Extras Quality Assurance
: 469042 528867 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2009-06-08 06:18 EDT by Corentin Perard-Gayot
Modified: 2015-01-14 18:23 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-12-05 01:52:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/var/log/messages (46.44 KB, text/plain)
2009-09-17 15:10 EDT, Sergey Rudchenko
no flags Details
messages Log File (209.14 KB, text/plain)
2010-04-29 19:33 EDT, William Makowski
no flags Details
log after initial login (31.85 KB, text/plain)
2010-04-29 19:36 EDT, William Makowski
no flags Details
log after logout (31.12 KB, text/plain)
2010-04-29 19:37 EDT, William Makowski
no flags Details
greeter log after initial login (18.90 KB, text/plain)
2010-04-29 19:37 EDT, William Makowski
no flags Details
greeter log after logout (17.79 KB, text/plain)
2010-04-29 19:38 EDT, William Makowski
no flags Details
slave log after initial login (44.57 KB, text/plain)
2010-04-29 19:41 EDT, William Makowski
no flags Details
slave log after logout (40.38 KB, text/plain)
2010-04-29 19:42 EDT, William Makowski
no flags Details
hack to always force active VT (787 bytes, patch)
2010-09-09 20:10 EDT, Michal Schmidt
no flags Details | Diff

  None (edit)
Description Corentin Perard-Gayot 2009-06-08 06:18:02 EDT
Description of problem:
gdm respawns in tty7 instead of tty1 after setting init mode to 1, then to 5 back

Version-Release number of selected component (if applicable):
I don't really know wether it's init- or gdm-related

How reproducible:

Steps to Reproduce:
1.boot. once in GDM, type CTRL+ALT+F2
2.log in as root, type "init 1", then "init 5" to switch back to graphical mode
3.type CTRL+ALT+F1 : nothing !!! then type CTRL+ALT+F7 : gdm is there 
Actual results:
gdm respawned in tty7

Expected results:
gdm respaws in tty1, as it runs there at boot time... it shouldn't move !

Additional info:
annoying bug since tty1 becomes unusable.
Comment 1 Sergey Rudchenko 2009-09-17 15:09:31 EDT
Thank you for the bug report.

Additional info:
This problem is reproducible on F11 and F12 rawhide as well.

F11: gdm-2.26.1-13.fc11.x86_64
F12: gdm-2.27.90-2.fc12.x86_64


Fedora Bugzappers volunteer triage team
Comment 2 Sergey Rudchenko 2009-09-17 15:10:58 EDT
Created attachment 361546 [details]

Here is the system log for gdm-2.27.90-2.fc12.x86_64 from 'init 3' to 'init 5'.
Comment 3 Sergey Rudchenko 2009-09-17 15:21:06 EDT
I guess gdm fails to start on tty1 because 'init 3' starts mingetty there
Comment 4 Sergey Rudchenko 2009-09-23 16:16:47 EDT
*** Bug 469042 has been marked as a duplicate of this bug. ***
Comment 5 iarly selbir 2009-10-26 13:37:38 EDT
After last updates, still problem persists?
Comment 6 Sergey Rudchenko 2009-10-26 17:41:44 EDT
Just tested on F12 Rawhide.

During the boot GDM was started on tty7 and remained there after 'init 3 && init 5'. Great!

But tty1 seems to be unused until 'init 3'. It shows only text cursor after boot. Why don't we just run mingetty there in 5th runlevel too?
Comment 7 Corentin Perard-Gayot 2009-10-27 20:20:25 EDT
Problem still persists in F11 :
* Fedora boots and gdm runs on tty1. After a init 3 -> init 5 gdm respawns in tty7, but tty1 becomes usable, a shell is launched.

I think it would be simpler to let gdm always run in tty1 not to confuse the user and to avoid any other problem this might cause.

another solution would be to always run gdm in tty7 but this move was intentional, if I remember well : it was for the flicker-free boot (from POST to GDM without any interruption)

Tell us about the advance on this problem... and if you need any other info (log, config file, version number)

Thanks in advance.
Comment 8 Bug Zapper 2009-11-16 05:01:59 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
Comment 9 Sergey Rudchenko 2009-12-05 16:28:25 EST
*** Bug 528867 has been marked as a duplicate of this bug. ***
Comment 10 William Makowski 2009-12-16 16:20:03 EST
I've been meaning to take a minute to comment on Bug 528867 being marked as a duplicate.  I'm okay with it because this bug and 528867 are definitely related, but a little bummed that my comments and debugging efforts are not as visible as they once were.  Que Sera Sera.

Previously I was not aware that tty's were shifting as a result of switching init modes.  This bug was noticed by me during the simple act of logging out from the desktop and logging back in.  It happens in both F11 and F12, but not F10.  This switching is quite annoying since the tty's and X do not remain in the same location.  I was blaming gdm more than the init scripts since it does not handle ensuring that Xorg starts on the same tty at all times.  While Xorg has the capability to pass the VT number as an argument during start up, as far as I can tell gdm does not have that ability as either a configuration option or argument.

Looking into this problem further I think it can be resolved without a great deal of coding by adjusting the upstart jobs and startup sequence within /etc/event.d.  If I understand upstart correctly, it is starting jobs by going through the /etc/event.d directory alphabetically.  I have no idea if this is true because the documentation is somewhat limited.  However, since prefdm is before tty[1-6] in the alphabet it gets started first and Xorg gets tty1 on initial boot.  I'm thinking if we start it after the tty's it would go back to tty7 and stay there, just like the majority of Linux distributions out there.  gdm always starts Xorg in the first available tty.  With tty[1-6] occupied it will be forced to put it in tty7.
Comment 11 Corentin Perard-Gayot 2009-12-17 11:41:54 EST
William : thanks for taking the time to comment here. However I don't agree with your solution :
if gdm is started in tty7, would the flicker-free boot still work ? I mean Plymouth seems to display its messages in tty1, so switching to tty7 to display gdm might make the screen flicker, Am I right ?
Comment 12 William Makowski 2009-12-17 12:58:48 EST
I made some mods to a few of the upstart jobs and ran a test today.  These changes allowed me to get gdm to stay put on tty7 when I logged out and logged back in.  I also tested switching runlevels, tty[1-6] remained available and gdm was always on tty7 in runlevel 5.  When I get a chance I'll compile a list of the changes I made just in case anyone is interested.

With regards to screen flicker there was a moment between plymouth boot status and gdm that tty1 was displayed.  It was very quick.  I felt the trade-off between getting gdm to stay put on tty7 versus tty1 being displayed during startup was worth it.  tty1 is also always available, whereas with the current setup, it becomes unusable.

Not sure if this is the ultimate solution, but it does work.  I'm thinking another solution would require changes to gdm so that it could be assigned a specific tty when started.  I'm just beginning to understand how all the jobs come together with upstart.  Seems like there will need to be more thought put into the sequencing of jobs.  Maybe the naming conventions in /etc/event.d will end up being similar to the numbering used on files in the /etc/rc.d/rcX.d directories.
Comment 13 Corentin Perard-Gayot 2010-01-16 17:36:32 EST
A little ping : is there some work in progress to resolve this issue ? I have also seen that F13 will come with new upstart : did anyone make a test with rawhide ?
Comment 14 William Makowski 2010-04-29 13:58:53 EDT
I did some testing on F13 Beta.  The good news is that changing init modes works.  The bad news is that a login followed by a logout is still a bug.  It looks like gdm or X crashes when you logout and when it restarts itself it moves the X session to tty7 since that is the next available tty.  tty1 continues to get abandoned during a logout.  That is where things stand going into the latest release of Fedora.
Comment 15 Ray Strode [halfline] 2010-04-29 16:34:29 EDT
Thanks for the update.

Can you add Enable=true to the [debug] section of /etc/gdm/custom.conf reproduce and then attach

/var/log/messages and /var/log/gdm 

Comment 16 William Makowski 2010-04-29 19:33:51 EDT
Created attachment 410263 [details]
messages Log File

This is the log from Rawhide (F13).  I copied everything from the point of restart. After the restart I logged in with a regular user, then logged out and logged back in.  Clock in Gnome was showing 19:06 at time of logout.
Comment 17 William Makowski 2010-04-29 19:36:34 EDT
Created attachment 410264 [details]
log after initial login
Comment 18 William Makowski 2010-04-29 19:37:19 EDT
Created attachment 410265 [details]
log after logout
Comment 19 William Makowski 2010-04-29 19:37:55 EDT
Created attachment 410266 [details]
greeter log after initial login
Comment 20 William Makowski 2010-04-29 19:38:32 EDT
Created attachment 410268 [details]
greeter log after logout
Comment 21 William Makowski 2010-04-29 19:41:46 EDT
Created attachment 410270 [details]
slave log after initial login
Comment 22 William Makowski 2010-04-29 19:42:58 EDT
Created attachment 410271 [details]
slave log after logout
Comment 23 Sergey Rudchenko 2010-07-09 01:48:44 EDT
It's interesting how things will change with the systemd (http://fedoraproject.org/wiki/Features/systemd). It's a new startup manager planned for F14.  Maybe it's worth reassigning the bug there?
Comment 24 William Makowski 2010-08-27 16:21:38 EDT
I have F14 Alpha running and the same problem exists with gdm moving from tty1 to tty7 after logging out.  If the problem is resolved by adjusting the startup sequence then systemd would be the place for this bug.  However, if finding out why gdm restarts after logging out is desirable then it should remain here.

systemd definitely adds a new landscape to Fedora.  After the install my system was starting up in runlevel 3 instead of 5.  Then after updating it started booting in rescue mode (that was new).  Changing the entry in inittab did nothing to correct the problem.  The link /etc/systemd/system/default.target was pointing to the wrong location.  If you run into the same problem, it needs to point to /lib/systemd/system/runlevel5.target which in turn points to /lib/systemd/system/graphical.target.
Comment 25 Michal Schmidt 2010-09-09 20:10:35 EDT
Created attachment 446401 [details]
hack to always force active VT

After boot gdm-simple-slave is run with the "--force-active-vt" parameter. After logout gdm-simple-slave is re-run, but without this parameter - so it runs on vt7 instead of vt1.

The attached patch makes gdm-binary always pass "--force-active-vt" to gdm-simple-slave. I am not proposing this as a fix. I'm pretty sure it would break something else. It's merely to point out why gdm moves to another VT after user logout.
Comment 26 Bug Zapper 2010-11-04 07:10:00 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 27 Bug Zapper 2010-12-05 01:52:24 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.