GDM logs out after some minutes of typing on the keyboard

[Sandro Mani]

Using Ubuntu Karmic x86_64, as of 06.07.09. Possibly relevant package:
gdm: Installed: 2.26.1-0ubuntu3

Problem:
After logging in via gdm (system freshly started up), after some minutes of typing (no matter in which program), I suddenly, without any warning, get kicked out of my session and back to the login screen. I suspect that this "event" is triggered by an unlucky but likely to occur key sequence. If I do not type anything the issue does not occur. There does not seem to be any single trigger key (i.e. the last key pressed before I get kicked out is not always the same one).
After re-logging back in, the issue does not occur anymore, until the next reboot.

Likely related symptoms:
- The first gdm session appears to start on tty1, the ones after the crash on tty7
- After the crash, if I switch to tty1, many random characters are printed, i.e.

$HOSTNAME login: *88;888;8;8<88A8
Ubuntu karmic (development branch) $HOSTNAME tty1

$HOSTNAME login: *1
Ubuntu karmic (development branch) $HOSTNAME tty1

[...]

$HOSTNAME login: 5.........215,1$9 1& 9 9!&SSSSS09!&,1/GHG.//79.1 4 *1"*2.99*1&,99*2*9*29*!9*24''''''*KKKKKKKKKKKKKKKKKKKKKKK.03KM/**********************
                                                                                       Pa
ssword:
Ubuntu karmic (development branch) $HOSTNAME tty1

$HOSTNAME login:
Ubuntu karmic (development branch) $HOSTNAME tty1

- GDM seemes to crash (it actually looks more like a controlled logout) when tty1 displays "password:"
- The above random characters have little to do with the ones I pressed.
- No related errors are to be found in any system log (which is why I suspect it is a controlled logout rather than a crash)

[Sandro Mani (sandromani)]

Maybe relevant: laptop has intel graphics (Mobile 4 Series Chipset Integrated Graphics Controller), therefore using KMS.

[Michael Rooney (mrooney)]

I had this happen as well with both 2.26.1-0ubuntu2 and 2.26.1-0ubuntu3.

[Martin Pitt (pitti)]

Can you please do

  sudo tar czf /tmp/gdm-logs.tar.gz /var/log/gdm

and attach /tmp/gdm-logs.tar.gz here?

[Martin Pitt (pitti)]

Potential duplicate of bug 395595.

[Sarah Kowalik (hobbsee-deactivatedaccount)]

Seeing this here as well. Attaching files.

[Martin Pitt (pitti)]

I don't get this at all, but then again gdm/X never start on vt1 for me. Did you do something to configure it that way?

[Scott James Remnant (Canonical) (canonical-scott)]

Nope, it just does that by default

[Martin Pitt (pitti)]

This was discussed in #ubuntu-devel. It seems many people get gdm on vt1 now, which collides with getty which is also on vt1. After some minutes this times out and shuts down the vt, taking X with it.

[Niall Creech (sevenmachines-deactivatedaccount)]

Might be helpful

seems i can regularly repeat the crash by booting as normal which gives,
- X starts on tty1
- open up something such as gnome-terminal
- type in several dozen characters press enter
- gdm crashes and restarts on tty7

In this scenario all the tty's are set to a US keymap which is wrong instead of UK like they should be.

But, if i now disable usplash on boot,
- X starts on tty7 as it should
- crash cannot be reproduced

With usplash disabled the tty's are all set to UK keymap as usual

[Scott James Remnant (Canonical) (canonical-scott)]

I suspect that what is going on is:

 - getty starts on tty1
 - X starts on tty1
 - since they're both on the same tty, they both receive the input, but the tty is now in RAW input mode so getty receive nonsense and choses to believe a Klingon is logging in
 - getty times out the login after a period of inactivity and exits
 - Upstart respawns the tty1 getty
 - the new getty claims ownership of the console
 - X is signalled that it has lost ownership of the console and exits

[Scott James Remnant (Canonical) (canonical-scott)]

If this hunch is true, running "sudo stop tty1" after login would likely stop the crash

[Martin Pitt (pitti)]

So either we drop /etc/event.d/tty1 completely, or gdm disables it somehow when it is installed.

[Niall Creech (sevenmachines-deactivatedaccount)]

"sudo stop tty1" certainly cures the problem here.
 is the problem that usplash has control of tty7 when gdm tries to start and so forces it onto tty1 instead?

[Michael Bienia (geser)]

From my syslog:
2009-07-07T09:38:55.720392+02:00 vorlon init: tty1 main process ended, respawning
2009-07-07T09:54:00.028547+02:00 vorlon init: tty1 main process ended, respawning
2009-07-07T10:04:08.124680+02:00 vorlon init: tty1 main process ended, respawning
2009-07-07T10:28:21.982215+02:00 vorlon init: tty1 main process ended, respawning
2009-07-07T10:31:50.216778+02:00 vorlon init: tty1 main process ended, respawning
2009-07-07T10:39:33.553337+02:00 vorlon init: tty1 main process ended, respawning
2009-07-07T10:52:14.286782+02:00 vorlon init: tty1 main process ended, respawning
2009-07-07T10:58:28.964354+02:00 vorlon init: tty1 main process ended, respawning
2009-07-07T11:05:40.036380+02:00 vorlon console-kit-daemon[3363]: WARNING: Unable to activate console: No such device or address
2009-07-07T11:05:40.118080+02:00 vorlon kernel: [ 5431.096333] [drm] Resetting GPU
2009-07-07T11:05:40.166167+02:00 vorlon kernel: [ 5431.158643] mtrr: MTRR 5 not used
2009-07-07T11:05:40.341633+02:00 vorlon acpid: client 3566[0:0] has disconnected
2009-07-07T11:05:40.341738+02:00 vorlon acpid: client connected from 21889[0:0]

I booted around 9:37 and 11:05 is the time I got kicked from X11 (I guess getty finally won).

[Niall Creech (sevenmachines-deactivatedaccount)]

or have gdm bring usplash down if its still sitting on tty7 when it starts so it can take over tty7

[Niall Creech (sevenmachines-deactivatedaccount)]

i'm confused, init.d/gdm checks for splash and brings it down, but we still end up on tty1. but if usplash isnt started on boot, all the problems go away and we end up on tty7

[Martin Pitt (pitti)]

gdm's init script doesn't shutdown splash, it still assumes that gdm is on a different terminal than vt1 and switches vt (which brings down usplash).

I discussed that with Scott, right now we don't yet have the right infrastructure to let gdm run on vt1. I'll move it back to 7 by default.

[Christopher (soft-kristal)]

In my case it seems to happen when pressing 'Enter', but infrequently. I recall entering a task in Thunderbird and pressing Enter to edit, composing an email message and pressing Enter for a new paragraph and login into my bank, pressing Enter after my password. The typing it self doesn't seem to be an issue.

[Martin Pitt (pitti)]

Sorry, in comment 17 I was lying. Of course gdm's init script stops usplash, but that's not actually the problem here.

The problem is that gdm's init script sleeps for 5 seconds _if_ usplash was running, to avoid having console output until X starts. These 5 seconds are enough to put the starting of getty so far out that gdm is already running and X grabbed vt1. Thus getty starts even though the VT is already taken.

[GiuseppeVerde (launchpad-digitasaru)]

Umm, can we get this fixed soon? I don't see a workaround aside from getting a fixed version of gdm, or did I miss something?

This problem is *extremely* annoying.

[Niall Creech (sevenmachines-deactivatedaccount)]

either,
- "sudo stop tty1" after logging into your gnome session
or,
- boot kernel without the splash option to stop it using usplash

both methods work on this computer

[Vincenzo Ciancia (vincenzo-ml)]

Dinxter ha scritto:
> either,
> - "sudo stop tty1" after logging into your gnome session
> or,
> - boot kernel without the splash option to stop it using usplash
>
> both methods work on this computer
>
>
I know support requests do not belong to bug reports but for the sake of
keeping relevant information in the same place, changing the #defopts=
... line in /boot/grub/menu.list does not work: update-grub restores the
configuration. Did something change in grub in karmic and how does one
permanently remove the splash option?

In the meantime it can be done at boot by pressing "e" and then... well,
I think grub has inline documentation.

[Niall Creech (sevenmachines-deactivatedaccount)]

i've set a thread here,
http://ubuntuforums.org/showthread.php?t=1206717
for problems with this bug as it is triaged

[ozhoo (colichia)]

same problem. working around with 'sudo stop tty1' after gnome logs in

[Michael Bienia (geser)]

For completeness: log out once after booting is also a workaround as after that gdm ends on tty7 and doesn't fight with getty about tty1 anymore.

[Vincenzo Ciancia (vincenzo-ml)]

Michael Bienia ha scritto:
> For completeness: log out once after booting is also a workaround as
> after that gdm ends on tty7 and doesn't fight with getty about tty1
> anymore.
>
>
This explained why one gets exactly one crash per reboot.

[Martin Pitt (pitti)]

I'm going to upload a really nasty workaround, but eventually it would be much better if we used the same dynamic schema for tty allocation everywhere.

Right now, getty is hardcoded at tty1 to 6, while X dynamically determines the next free terminal. As this bug shows, this represents a race condition, and will break if X starts earlier than getty.

It would be much better if the getty invocation would be done to "take the next free tty" instead of a fixed one. Then we wouldn't need any hardcoding at all any more.

[Vincenzo Ciancia (vincenzo-ml)]

Il 09/07/2009 15:25, Martin Pitt ha scritto:
> It would be much better if the getty invocation would be done to "take
> the next free tty" instead of a fixed one. Then we wouldn't need any
> hardcoding at all any more.
>

Here there is something I don't understand: either an (advanced) user is
supposed to be allowed to use the ttys or not. If she is allowed, for a
matter of usability, the gdm tty should be a fixed one, so that the user
has a way to get back to gdm without having to guess the tty.

[James Schriver (dashua)]

I know the GDM is buggy on Karmic, but I just had a random crash. Not sure if this will help de-bug.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gdm - 2.26.1-0ubuntu5

---------------
gdm (2.26.1-0ubuntu5) karmic; urgency=low

  * debian/gdm.preinst: Remove obsolete conffiles.
  * debian/gdm.preinst: Migrate autologin settings from gdm.conf (which isn't
    read any more) to custom.conf. (LP: #396459)
  * Add 81_initial_server_on_vt7.patch: Force initial X server to go to tty7
    instead of tty1. This is an Ugly Hack until we have a cleaner solution for
    getty not to tramp over a running X server on vt1. This bandaids the
    immediate problem of the first X server being killed after a few minutes
    due to getty on tty1 timing out. (LP: #396226)

 -- Martin Pitt <email address hidden> Thu, 09 Jul 2009 18:08:07 +0200

[jerrylamos (jerrylamos)]

On one of my pc's I get a random login, on this IBM ThinkCentre with Intel i845 I get a "black screen of death" where nothing works except power off.

sudo edit /etc/default/grub

remove:

splash

sudo update-grub

then reboot fixed it I think because it's been running for hours. See my bug 396843 for logs etc. however it does look like this bug is well understood.

Thanks for the workaround.

Jerry

[Scott James Remnant (Canonical) (canonical-scott)]

On Thu, 2009-07-09 at 14:04 +0000, Vincenzo Ciancia wrote:

> Il 09/07/2009 15:25, Martin Pitt ha scritto:
> > It would be much better if the getty invocation would be done to "take
> > the next free tty" instead of a fixed one. Then we wouldn't need any
> > hardcoding at all any more.
> >
>
> Here there is something I don't understand: either an (advanced) user is
> supposed to be allowed to use the ttys or not. If she is allowed, for a
> matter of usability, the gdm tty should be a fixed one, so that the user
> has a way to get back to gdm without having to guess the tty.
>
If the gdm tty is fixed, the X tty has to be fixed too.

We can do "all ttys fixed" or "all ttys dynamic", an attempt to do both
gives us the bug we currently have.

Scott
--
Scott James Remnant
<email address hidden>

[Scott James Remnant (Canonical) (canonical-scott)]

On Thu, 2009-07-09 at 13:25 +0000, Martin Pitt wrote:

> It would be much better if the getty invocation would be done to "take
> the next free tty" instead of a fixed one. Then we wouldn't need any
> hardcoding at all any more.
>
One advantage for this is that we could actually use the kernel
"Keyboard Request" signal for the purpose with which it was intended.

Alt+UpArrow would be "give me a new getty"

Scott
--
Scott James Remnant
<email address hidden>

[Vincenzo Ciancia (vincenzo-ml)]

Then I would suggest (out of the scope of this bug) to reserve a key
combination (perhaps there already is one?) that takes you "back to the
last X tty"; this would eliminate the need for guessing the tty.

[Ramón Rocha (ramon.rocha)]

I was doing some testing of lucid today for the nvidia prop. drivers and am getting behavior that sounds the same as this bug. How can I verify it's the same issue?

[Martin Karlsson (foh1981)]

Ramon:
Are you sure that it's the same bug? I'm in the same position as you, I'm testing the proprietary drivers, but for me it's not a timed issue neither is it with completely random characters. I always get logged out when I'm entering my password for the wireless network, specifically when typing @. When I log in again it works without problems. I've filed a new bug here: https://bugs.launchpad.net/ubuntu/+source/gnome-desktop/+bug/522554

[Ramón Rocha (ramon.rocha)]

Martin, you are right, it's not a time issue and I was also able to consistently reproduce it when hitting the number '2' key (or @ key as described in your bug) on my keyboard.

[Maxim Levitsky (maximlevitsky)]

Actually this workaround doesn't work on my desktop for some strange reason.
X starts on vt1, of course hangs due to fight with plymouth,
The /var/run/gdm/firstserver.stamp exists, and I tested that x doesn't crash first time or so.
Removing it makes X start on vt7, on next boot everything is back....
/var/run is mounted as tmpfs, and I did check that it doesn't contain /var/run/gdm/firstserver.stamp if booted into 'single' mode

[Maxim Levitsky (maximlevitsky)]

Boy, how ugly things could get.
I was wrong about X not crashing. It indeed crashes once.
I have here a custom built from latest git trees x server, and it is of course ubuntu hack free...

So it turns out that plymouth (or whatever the name is) makes X crash, and ubuntu xserver carries a patch (for very long time I'll say, because its second time I face this, I just forgot), that workarounds that problem....
(121_only_switch_vt_when_active.diff)

I understand carrying patches when you choose stable version and cherry picked changes from latest tree, or you put a patch and soon submit it, but this is ridiculous.

Btw, that 'seamless' boot patches (-bg none) aren't upstream too, and intel driver changed so much that it easier to study the whole thing that to try and apply it....

Folks, really send patches upstream, its for the common good.

[Bruno França dos Reis (bfreis)]

I see the exact same symptoms in Oneiric x64:

 - it happens once every boot, after a few minutes;
 - it happens systematically right when I press the Enter key (not the first time, don't know if it is always at the N-th time);
 - tty1 gets lots of crap (not always the same characters, but always the same pattern, and it is the same pattern as in the original bug report)

I noticed that before the crash X is at "ctrl+alt+f7", and after the crash it goes to "ctrl+alt+f8".

I don't know how to add "Oneiric" to the list of affected distributions in the top of this page. I tried to do so by linking a branch without success.