Three users switching leads to blank tty9

Bug #40011 reported by mannheim
52
This bug affects 8 people
Affects Status Importance Assigned to Milestone
gdm
Fix Released
Low
gdm (Ubuntu)
Incomplete
Medium
Unassigned

Bug Description

Using dapper's gdm and the "switch user" funcionality available in the "log out" dialog, do:

1. Login as user "A".
2. From A's desktop, switch user and login as "B".
3. From B's desktop, switch user and login as "C".
4. From C's desktop switch back to B (resume session).
5. As B, log out (this returns you to "A").
6. From A's desktop switch user to C (resume session).
7. As C, log out.

After step 7, you find yourself at a blank tty9 with a blinking cursor.

Explanation: users A, B and C are on tty7, tty9 and tty10 by default. When "B" logs out, tty9 becomes blank. When "C" logs out later from tty10, the screen is retuned to tty9. The logic in gdm needs to be changed. When "C" logs out, the user should be returned to tty7 in this situation (or to a new gdm screen).

Please note, this is a bug in the logic of gdm, not a display/video driver issue. It is 100% reproducible on my machine at least.

Simon Law (sfllaw)
Changed in gdm:
status: Unconfirmed → Confirmed
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for your bug. I've forwarded it upstream: http://bugzilla.gnome.org/show_bug.cgi?id=343539

Changed in gdm:
assignee: nobody → desktop-bugs
Changed in gdm:
status: Unconfirmed → Confirmed
Changed in gdm:
status: Confirmed → Triaged
Revision history for this message
Robert Ancell (robert-ancell) wrote :

Closing as this functionality is sufficiently different in Ubuntu 9.10 so that it cannot be reproduced. Please re-open if you can reproduce this problem in Ubuntu 9.10.

Changed in gdm (Ubuntu):
status: Triaged → Won't Fix
Revision history for this message
Jani Uusitalo (uusijani) wrote :

I can reproduce this in up-to-date Karmic, using precisely the steps described above.

Changed in gdm (Ubuntu):
status: Won't Fix → Confirmed
Revision history for this message
Jani Uusitalo (uusijani) wrote :

As a quick (and probably nasty) workaround, I added "/bin/chvt 7" to /etc/gdm/PostSession/Default. At least the non-savvy users of this system aren't faced with a blank tty ever, though I'm not at all sure they're safe from other, unintended implications of my solution.

Revision history for this message
Dominique Cimafranca (dominiquec) wrote :

I have the same problem in Lucid.

Revision history for this message
quiritius (quiritius) wrote :

I have also in Lucid. This is obviously must be fixed since one-user systems also are effected.
When you log out for graphic session and return to GDM login screen AND enter a tty[1-6] (no need to actually log in, you just have to see the text prompt), you will get an empty tty7 and the GDM login screen is moved to tty8.

Revision history for this message
Ben Aisen (beinsane11) wrote :

I can confirm the same behavior as quiritius, although since it doesn't involve user switching it may not be the same as the original bug. Could there be some weird interaction with plymouth?

Revision history for this message
Erik Meitner (e.meitner) wrote :

Created /etc/gdm/custom.conf:
[daemon]
[security]
[xdmcp]
[greeter]
[chooser]
[debug]
Enable=true

Rebooted.

Loged in three users. Logged them out one by one. Attached is what was logged in /var/log/daemon.log when the last user was logging out and the screen was left at a blank VT

After that I ran these commands:
$ sudo fgconsole
9
$ ck-list-sessions
Session14:
 unix-user = '114'
 realname = 'Gnome Display Manager'
 seat = 'Seat1'
 session-type = 'LoginWindow'
 active = FALSE
 x11-display = ':0'
 x11-display-device = '/dev/tty8'
 display-device = ''
 remote-host-name = ''
 is-local = TRUE
 on-since = '2010-05-13T17:22:28.408652Z'
 login-session-id = '4294967295'
Session7:
 unix-user = '1000'
 realname = 'sysadmin'
 seat = 'Seat2'
 session-type = ''
 active = FALSE
 x11-display = ''
 x11-display-device = ''
 display-device = '/dev/ssh'
 remote-host-name = 'cheren.int.willystreet.coop'
 is-local = FALSE
 on-since = '2010-05-13T17:17:06.784808Z'
 login-session-id = '4294967295'

Revision history for this message
Erik Meitner (e.meitner) wrote :

These Gentoo bug reports have some interesting discussions about similar issues:
http://bugs.gentoo.org/show_bug.cgi?id=312017
http://bugs.gentoo.org/show_bug.cgi?id=261339
http://bugs.gentoo.org/show_bug.cgi?id=288852
The patch in 312017 (comment 9) does not apply cleanly I'll try to get it to apply this weekend.

Hours of searching has turned up little else.

This bug is quite important to those of us trying to implement multi-user workstations with the flexibility of multiple logged-in users. We can't expect users to know about CTL-ALT-Fx commands in order to get access to a login prompt.

Is it known whether this bug affects ALL 10.04 systems with GDM? If the answer is yes, does not not deserve this bug to have an importance higher than "Low"?

Revision history for this message
Erik Meitner (e.meitner) wrote :

After reviewing https://wiki.ubuntu.com/Bugs/Importance I am asking that someone with the required access change the importance of this bug from Low to Medium because this bug is:
# One that can NOT be easily worked around by non-technical end users
# NOT due to unusual configurations or uncommon hardware
# NOT A bug that has a moderate impact on a non-core application. GDM is a core application.
# NOT A cosmetic/usability issue that does not limit the functionality of an application

Revision history for this message
John Baptist (jepst79) wrote :

I agree with Erik Meitner. This bug prevents user switching entirely. If I accidentally select "Swich From" on a single-user system, I have to kill my session or reboot to continue. Serious functionality issue.

Revision history for this message
Erik Meitner (e.meitner) wrote :

Jeff, Make sure you are not actually affected by bug 546578. There is already a fixed gnome-screensaver package in lucid/proposed that resolves that issue.

Erik Meitner (e.meitner)
tags: added: blank console gdm switch user vt
Revision history for this message
Rick Spencer (rick-rickspencer3) wrote :

While I very much doubt this is the same issue that was effecting users in dapper, none the less, I am easily able to repro a similar issue locally.

Changed in gdm (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → Canonical Desktop Team (canonical-desktop-team)
importance: Low → Medium
Revision history for this message
Sebastien Bacher (seb128) wrote :

The gdm codebase has changed since so the karmic issue is likely a different one, let's use this bug though to avoid extra work, Robert could you have a look to the issue and see if you can figure what is going wrong?

Changed in gdm (Ubuntu):
assignee: Canonical Desktop Team (canonical-desktop-team) → Robert Ancell (robert-ancell)
Changed in gdm (Ubuntu):
status: Confirmed → Triaged
Changed in gdm:
status: Confirmed → Fix Released
Changed in gdm (Ubuntu):
assignee: Robert Ancell (robert-ancell) → nobody
Changed in gdm:
importance: Unknown → Low
Revision history for this message
Erik Meitner (e.meitner) wrote :

I just tested Maverick and it also has the bug.

So does anybody know if the fix that exists upstream can be backported? I was unable to get a response from the developer in the upstream bug report about this.

Revision history for this message
Erik Meitner (e.meitner) wrote :

I've created a workaround for this bug.

1. Copy the attached file to /usr/local/bin/
2. sudo chmod 755 /usr/local/bin/gdm_vt_fixer
3. Add the following to /etc/gdm/PostSession/Default before the "exit 0" command:
/usr/local/bin/gdm_vt_fixer &
4. Restart GDM or reboot.

The script will be run after a GDM session ends(a user logs out). It will wait five seconds and then check that the virtual terminal that is active is associated with an existing X session. If it is not, it will switch to a VT that is running the login window. If there is no login window it will switch to a VT of some existing X session.

Revision history for this message
Erik Meitner (e.meitner) wrote :

I must have grabbed an older version of the script. This has the required 5 second wait that the previous one did not.

Revision history for this message
Marius B. Kotsbak (mariusko) wrote :

This is fixed upstream a long time ago. Can anyone reproduce this in a recent Ubuntu version?

Changed in gdm (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
Jani Uusitalo (uusijani) wrote :

Not reproducible in current 12.10 with gdm 3.6.0-0ubuntu4, still reproducible in 12.04 with gdm 3.4.0-0ubuntu15.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.