gdm >= 2.24: random logouts and tty2 weirdness

[Fran]

I'm playing with gnome 2.26, and I though that I could give gdm-2.26 a try. Well, I like it quite a lot (even with its default unchangeable theme), but I have a big problem: ever since I updated, I experience random logouts from gnome. I'm writing something in an editor, or firefox, or terminal, and suddenly the screen goes black and back to the gdm login greeter. It happens with gdm-2.24, too. When it happens I see a lot of garbage output in tty2. This is what the log shows (I logged in at 8:08, and I was dumped at 8:54):

Code: Select all

Mar 28 08:08:47 xps gdm-session-worker[2385]: pam_unix(gdm:session): session opened for user franjva by (uid=0)
Mar 28 08:52:29 xps login[2391]: pam_tally(login:auth): pam_get_uid; no such user
Mar 28 08:53:55 xps login[17200]: pam_tally(login:auth): pam_get_uid; no such user
Mar 28 08:54:44 xps login[17200]: pam_unix(login:auth): check pass; user unknown
Mar 28 08:54:44 xps login[17200]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= 
Mar 28 08:54:46 xps gdm-session-worker[2385]: pam_unix(gdm:session): session closed for user franjva
Mar 28 08:54:46 xps gnome-keyring-daemon[2405]: dbus failure unregistering from session: Connection is closed
Mar 28 08:54:47 xps login[17200]: FAILED LOGIN (1) on 'tty2' FOR `UNKNOWN', User not known to the underlying authentication module
Mar 28 08:54:47 xps login[17200]: pam_securetty(login:auth): unexpected response from failed conversation function
Mar 28 08:54:47 xps login[17200]: pam_securetty(login:auth): cannot determine username
Mar 28 08:54:47 xps login[17200]: pam_tally(login:auth): pam_get_user; user?
Mar 28 08:54:47 xps login[17200]: pam_nologin(login:auth): cannot determine username
Mar 28 08:54:49 xps login[17200]: FAILED LOGIN (2) on 'tty2' FOR `UNKNOWN', Error in service module
Mar 28 08:54:49 xps login[17200]: pam_securetty(login:auth): unexpected response from failed conversation function
Mar 28 08:54:49 xps login[17200]: pam_securetty(login:auth): cannot determine username
Mar 28 08:54:49 xps login[17200]: pam_tally(login:auth): pam_get_user; user?
Mar 28 08:54:49 xps login[17200]: pam_nologin(login:auth): cannot determine username
Mar 28 08:54:52 xps login[17200]: TOO MANY LOGIN TRIES (3) on 'tty2' FOR `UNKNOWN'
Mar 28 08:54:52 xps login[17200]: pam_mail(login:session): cannot determine username
Mar 28 08:54:52 xps login[17200]: pam_unix(login:session): close_session - error recovering username
Mar 28 08:55:10 xps gdm-session-worker[17275]: pam_unix(gdm:session): session opened for user franjva by (uid=0)

I didn't go to tty2 to do anything, so I don't understand what starts happening at 8:52. It's as if something was dumping output to tty2, the system took it as if someone was trying to login, and gdm logs me out when the login in tty2 fails.

Anyone else has experienced this?

[vaxbrat]

Sounds like your video device driver, app software or even the hardware is causing the X server to reset. That's why you get the black screen followed by the gdm login panel.

[Fran]

Sounds like your video device driver, app software or even the hardware is causing the X server to reset. That's why you get the black screen followed by the gdm login panel.

That wouldn't explain the log messages just before the logout. Another example that happened some minutes ago:

Code: Select all

Mar 28 12:37:06 xps gdm-session-worker[2384]: pam_unix(gdm:session): session opened for user franjva by (uid=0)
Mar 28 15:09:21 xps login[3020]: pam_tally(login:auth): pam_get_uid; no such user
Mar 28 15:09:28 xps gdm-session-worker[2384]: pam_unix(gdm:session): session closed for user franjva
Mar 28 15:09:28 xps gnome-keyring-daemon[2404]: dbus failure unregistering from session: Connection is closed
Mar 28 15:09:30 xps login[3020]: pam_unix(login:auth): auth could not identify password for [00`I`I`K`K]
Mar 28 15:09:33 xps login[3020]: FAILED LOGIN (1) on 'tty2' FOR `UNKNOWN', User not known to the underlying authentication module
Mar 28 15:09:33 xps login[3020]: pam_securetty(login:auth): unexpected response from failed conversation function
Mar 28 15:09:33 xps login[3020]: pam_securetty(login:auth): cannot determine username
Mar 28 15:09:33 xps login[3020]: pam_tally(login:auth): pam_get_user; user?
Mar 28 15:09:33 xps login[3020]: pam_nologin(login:auth): cannot determine username
Mar 28 15:09:36 xps login[3020]: FAILED LOGIN (2) on 'tty2' FOR `UNKNOWN', Error in service module
Mar 28 15:09:36 xps login[3020]: pam_securetty(login:auth): unexpected response from failed conversation function
Mar 28 15:09:36 xps login[3020]: pam_securetty(login:auth): cannot determine username
Mar 28 15:09:36 xps login[3020]: pam_tally(login:auth): pam_get_user; user?
Mar 28 15:09:36 xps login[3020]: pam_nologin(login:auth): cannot determine username
Mar 28 15:09:40 xps login[3020]: TOO MANY LOGIN TRIES (3) on 'tty2' FOR `UNKNOWN'
Mar 28 15:09:40 xps login[3020]: pam_mail(login:session): cannot determine username
Mar 28 15:09:40 xps login[3020]: pam_unix(login:session): close_session - error recovering username
Mar 28 15:09:48 xps gdm-session-worker[3761]: pam_unix(gdm:session): session opened for user franjva by (uid=0)

There are no segfaults registered in Xorg.0.log. And it happens with different video drivers AND diferent xorg-servers. Oh, and it does not happen if I go back to gdm-2.20. This is definitely a gdm issue, not a driver/xserver issue.

[vaxbrat]

Are you running out of your local passwd or using a mapping to something else such as ADS, NIS or some form of ldap? I've seen at least one case (Samba/Windbind to ADS) where a winbindd bug caused it to lose its lunch about once a day and exit. At that point, username mapping from the ADS server was busted. That pam error smells like something similar

[Fran]

Thanks, but no, just plain local login. It just happened again:

Code: Select all

Mar 29 08:23:26 xps gdm-session-worker[2388]: pam_unix(gdm:session): session opened for user franjva by (uid=0)
Mar 29 09:13:39 xps login[2716]: pam_tally(login:auth): pam_get_uid; no such user
Mar 29 09:13:42 xps login[2716]: pam_unix(login:auth): auth could not identify password for [&&88.  99`I`I88`[`K`[`K`[`[`[`[]
Mar 29 09:13:45 xps login[2716]: FAILED LOGIN (1) on 'tty2' FOR `UNKNOWN', User not known to the underlying authentication module
Mar 29 09:13:45 xps login[2716]: pam_securetty(login:auth): unexpected response from failed conversation function
Mar 29 09:13:45 xps login[2716]: pam_securetty(login:auth): cannot determine username
Mar 29 09:13:45 xps login[2716]: pam_tally(login:auth): pam_get_user; user?
Mar 29 09:13:45 xps login[2716]: pam_nologin(login:auth): cannot determine username
Mar 29 09:13:48 xps login[2716]: FAILED LOGIN (2) on 'tty2' FOR `UNKNOWN', Error in service module
Mar 29 09:13:48 xps login[2716]: pam_securetty(login:auth): unexpected response from failed conversation function
Mar 29 09:13:48 xps login[2716]: pam_securetty(login:auth): cannot determine username
Mar 29 09:13:48 xps login[2716]: pam_tally(login:auth): pam_get_user; user?
Mar 29 09:13:48 xps login[2716]: pam_nologin(login:auth): cannot determine username
Mar 29 09:13:51 xps login[2716]: TOO MANY LOGIN TRIES (3) on 'tty2' FOR `UNKNOWN'
Mar 29 09:13:51 xps login[2716]: pam_mail(login:session): cannot determine username
Mar 29 09:13:51 xps login[2716]: pam_unix(login:session): close_session - error recovering username
Mar 29 09:13:59 xps gdm-session-worker[2960]: pam_unix(gdm:session): session opened for user franjva by (uid=0)

And another weird thing: the first time I log in in GDM, X is launched in tty2. After I'm kicked out and I log in again, X is in tty7, as it's always been. Maybe that explains this: the problem with the random logout only happens once. No matter how long I'm logged in after the first time I'm kicked out, there are no problems. I'm quite sure that the garbage output I'm seeing in tty2 when I log the second time (I cannot see it the first time I log in, because that's where the X server is running) is what causes the logouts.

Now the question is: why the hell is the X server running in tty2 at boot time and how can I change this?

PS: now that I think about it, this may be related to running gdm too soon, maybe? Is it possible that gdm runs on the first unused tty, and since the login processes (that usually pick tty1-6) are not yet running it picks tty2? And then the login starts at tty2 too and causes this weird behavior?

PS2: while I was writing the previous I've found this in /etc/init.d/xdm:

Code: Select all

# Any Display manager (gdm,kdm,xdm) has the following problem:  if
# it is started before any getty, and no vt is specified, it will
# usually run on vt2.  When the getty on vt2 then starts, and the
# DM is already started, the getty will take control of the keyboard,
# leaving us with a "dead" keyboard.
#
# Resolution: add the following line to /etc/inittab
#
#  x:a:once:/etc/X11/startDM.sh
#
# and have /etc/X11/startDM.sh start the DM in daemon mode if
# a lock is present (with the info of what DM should be started),
# else just fall through.

Well, it seems my problem is not that I get a dead keyboard, but a keyboard that works in both X and tty2 at the same time . The keypresses are passed to the login process behind X, and somehow that makes gdm kick me out when something happens in tty2.

I'll file a bug. I have that line in inittab but it does nothing.

Also, it's weird nobody else has experienced this (I've seen other people in the forums are using gdm>=2.24)

PS3: meh, there is already a filed bug where the problem is described . I could not find it when I created the thread.

[Insanity5902]

I was experiencing this with 2.24 , gave up and downgraded, now with 2.26, having the exact some issues as you.

I have found that when I first login to gnome, to go ahead and log back out, and it is a quick fix. I haven't read the bug yet, about to do it, but that is what I found to get around the issue instead of waiting for it to happen. It seems to happen in about the first 10 - 15 minutes of the very first login through gdm.

[Fran]

I was experiencing this with 2.24 , gave up and downgraded, now with 2.26, having the exact some issues as you.

I have found that when I first login to gnome, to go ahead and log back out, and it is a quick fix. I haven't read the bug yet, about to do it, but that is what I found to get around the issue instead of waiting for it to happen. It seems to happen in about the first 10 - 15 minutes of the very first login through gdm.

I was going to tell you that there is an easier way (commenting the tty2 line in inittab) but I see that somebody already answered that on the bug report.

[gringo]

I was going to tell you that there is an easier way (commenting the tty2 line in inittab) but I see that somebody already answered that on the bug report.

yep, was going to suggest the same.
But looking to the errors you posted couldn´t this be somehow related to pam or gnome-keyring ?

now that I think about it, this may be related to running gdm too soon, maybe? Is it possible that gdm runs on the first unused tty, and since the login processes (that usually pick tty1-6) are not yet running it picks tty2? And then the login starts at tty2 too and causes this weird behavior?

unless you are doing some magic voodoo in your inittab or somewhere else, that wouldn´t make much sense i think, but maybe worth a try. Does it work fine of you have xdm in the default runlevel f.ex.?

I havent checked myself but is there some option in gdm´s configuration file were you can specify the tty to use or to override pam setup ?
I use gdm myself randomly and never had an issue like this one BTW.

cheers

[Fran]

But looking to the errors you posted couldn´t this be somehow related to pam or gnome-keyring ?

No, it's definitely caused by gdm running in the same tty as another login process. I commented the tty2 line in inittab a week ago, just after I found the bug, and the problem disappeared. And as I mentioned in the bug report (I'm Francisco there) this only happens when gdm is run in the default runlevel, and only the first time. If I run it manually, it starts at tty7. If leave it in the runlevel, log in and then log out, it goes from tty2 to tty7 (as Insanity5902 said).

So either gdm doesn't detect that tty2 is busy at boot (probably a gdm bug, but it'd be weird because it works if it is started manually) or tty2 is not busy when gdm starts (also weird).

[Mr. Tao]

Same thing (gdm on vt2) happened to me when I had some problems with ttys regarding udev. Just out of curiosity, are you running openrc with rc_parallel="YES"?

[Fran]

Same thing (gdm on vt2) happened to me when I had some problems with ttys regarding udev. Just out of curiosity, are you running openrc with rc_parallel="YES"?

Yes. But even if that's the source of the problem, I'll continue to use it , it's one of the best things of openrc. If gdm-2.20 works with rc_parallel, so should gdm-2.26.

[Insanity5902]

Thanks guys for the hint at the inittab, didn't even think of editing it.

As for the parallel boot up, I tested it out with it off , same issue. Slim and the gdm-2.20 worked fine with the exact same setup.

I had the same problem with gdm-2.24, It is a bug with the gdm system, I believe it was a complete re-write from 2.20.

[arian]

Just registered to say this:

I'm using Arch in two computers, and i'm experiencing this fu**ing bug too.

The weird thing is that I just realized that GDM is on tty2!!! When i switch to tty7 it's like halted, waiting for something (just an intermitent cursor, no text), so login isn't running there.

[arian]

Which implies that both GDM and login are running on the same tty!!!

Check this out: when it crashes, gdm restarts on tty7 and graphical login appears. But, if you manually switch to tty2 JUST AFTER it crushes (before graphical login appeares) you see a bunch of text in the login prompt. But you have to be fast, because login restarts and tje text is deleted. Is there any way to see the previous text in a login tty? I've tried Caps+PageUp but it doesn't work :S.

[bloodstix]

Hi,

i know this topic is old, but i wanted to CONFIRM this as Bug.
I had this Problem with OLWM. Crashed all time you did
kill -9 hald in xterm in started olwm. But just the first time.
The times after, it say "parameter has to be integer".

You can resolve this issue by commenting out the line with tty2 in /etc/inittab