Gnome login hangs every time using XDMCP

[Billy Charlton]

Binary package hint: gnome-keyring

System:
Fresh install of Hardy Heron desktop CD (i386), 1-Feb-2008. System: 1GB Ram, Intel Core 2 Duo, 2.0Ghz. Gnome login & desktop works fine from local console.

Steps to reproduce bug:
1) System - Admin - Login Window:
       - Allow remote logins
       - Uncheck "Deny TCP connections"
       - Restart
2) Go to another box on your local network, choose "XDMCP Browse" and get a GDM login screen to the Hardy machine. I'm using Xming from Win XP, if that makes any difference
3) Pretty Ubuntu GDM login screen shows up fine, so enter your credentials
4) Machine hangs with nothing but a blank, light orange background color

If I then use ssh to log in to the Hardy machine, I see with ps that a process "gnome-keyring-daemon -d --login" is just sitting there, being run by the user I attempted to log in. It's not using any CPU though, just seems to be hanging/deadlocked? Manually killing that process doesn't help, light orange screen just sits there.

I've read the other recent (similar) bugreports on gnome-keyring-daemon but this seems different, as it only affects XDMCP logins. Could be related to those other reports (157622, 175682, 179377) but I never have trouble logging in from the local console.

Let me know what else I can provide to help triage.

[Billy Charlton (billy)]

Also affects gutsy, just tested on a clean gutsy with all updates installed (same hardware).

[Sebastien Bacher (seb128)]

Thank you for your bug. That doesn't seems to be a gnome-keyring issue, why do you think it's due to this one?

[Billy Charlton (billy)]

You're correct; I don't know that the bug is in gnome-keyring for certain. What I do know is that the gnome login process hangs at gnome-keyring-daemon.

Is there a way I can test a gnome login without the keyring daemon, to eliminate that as the culprit? I'm happy to provide any other info you may need, if you can just point me in the right direction to help out.

[Sebastien Bacher (seb128)]

you can switch to a vt and stop the gnome-keyring-daemon from there and see if that unlocks the login, you can also try to move the binary before login and see if that works

[Billy Charlton (billy)]

Strange. I've done a few tests and here's some additional info. I tried a few other paths to see if the problem lay somewhere other than XDMCP but the problem does seem related to XDMCP logins only.

1) I've updated to the latest hardy packages as of 12-Feb-2008.

2) Local logins still work fine.

3) I set up Xvnc to test vnc-based GDM logins, and I can now remotely log in using Xvnc with no troubles.

4) Using standard remote GDM logins via XDMCP still exhibits the orignal behavior: I see the GDM login screen, and can enter my credentials, but after clicking OK, the screen just goes to the blank light-orange and sits there.

5) I can then use SSH to log into a terminal session. Using 'ps ux' I see the following processes, on most attempts:
      billy 9900 0.0 0.2 7924 2576 ? Ss 16:52 0:00 /usr/bin/pulseaudio --log-target=syslog
      billy 9901 0.0 0.2 5928 2332 ? S 16:52 0:00 /usr/lib/pulseaudio/pulse/gconf-helper
      billy 10215 0.1 0.3 6964 3784 ? S 16:54 0:00 /usr/lib/libgconf2-4/gconfd-2 14
      billy 10244 0.0 0.1 6372 1832 ? S 17:00 0:00 /usr/bin/gnome-keyring-daemon -d --login

But sometimes on login I get this instead:
      billy 9746 2.3 0.3 6972 3784 ? S 16:44 0:00 /usr/lib/libgconf2-4/gconfd-2 4
      billy 9748 0.0 0.2 14612 2084 ? S 16:44 0:00 /usr/bin/gnome-keyring-daemon -d --login
      billy 9749 0.6 0.6 28600 6904 ? Ssl 16:44 0:00 x-session-manager
      billy 9795 0.5 0.6 25296 6284 ? Ss 16:44 0:00 /usr/bin/seahorse-agent --execute x-session-manager
      billy 9803 0.0 0.0 2772 828 ? Ss 16:44 0:00 dbus-daemon --fork --print-address 24 --print-pid 26 --ses
      billy 9804 0.3 0.6 20804 6296 ? S 16:44 0:00 gnome-settings-daemon

None of these processes is using any CPU. I've tried killing them one at a time, in order, but don't get anything on the XDMCP screen but the orange background.

Question: Do gnome-keyring-daemon, gconfd or x-session-manager use network ports other than what XDMCP is already using? I know XDMCP itself uses UDP 177, and that seems to be working properly since I do get the GDM login screen correctly. I don't expect that this is a firewall issue but I want to cover all the bases.

[Billy Charlton (billy)]

I've also tried renaming the gnome-keyring-daemon, and now on a login attempt I get the orange background and absolutely no processes in the terminal from this user according to 'ps'. So it's pretty safe to assume that gnome-keyring-daemon is not the culprit. Still no clue what the culprit is, however.

I'll keep digging. This is really starting to feel like some sort of local firewall issue.

[Billy Charlton (billy)]

My IT guys insist they're not blocking anything on our local network.

[Billy Charlton (billy)]

Some info, which I think points to the problem. I used XDMCP to start a "Failsafe Terminal" session. (Both libgconf and gnome-keyring-daemon still start up even with failsafe terminal, which I didn't realize used any gnome services. Strange).

From the xterm window in the lower right, I type "gnome-session" and see a slew of debug messages. The process hangs every time at the same spot:

$ gnome-session
...
...
** (gnome-settings-daemon:6392): DEBUG: Loading /usr/lib/gnome-settings-daemon-2.0/libsound.so
** (gnome-settings-daemon:6392): DEBUG: Registering GsdSoundPlugin
** (gnome-settings-daemon:6392): DEBUG: Creating object of type GsdSoundPlugin
** (gnome-settings-daemon:6392): DEBUG: GsdSoundPlugin initializing
** (gnome-settings-daemon:6392): DEBUG: Activating sound plugin
** (gnome-settings-daemon:6392): DEBUG: Starting sound manager

and then, nothing. Notably, this hardware does not have a sound card. I will try and find a different machine with built-in sound and see if the problem goes away. In the meanwhile, is there a way I can disable the startup of the sound manager, in order to verify that it is the culprit here? Remember that this is an XDMCP-only problem; I don't have trouble logging in locally.

[Billy Charlton (billy)]

Sorry, that was a red herring. I figured out how to disable the gnome-settings-daemon plugins by moving the *plugin files from /usr/lib/gnome-settings-daemon-2.0, but removing those plugins had no effect on the login procedure. Still just greeted with a blank screen, *or* sometimes a lone blank dialog window with no text or widgets, (but is clearly the usual dialog saying that gnome-settings-daemon unexpectedly quit or couldn't start.)

Not sure what else to try here, but the problem on Hardy persists.

[Billy Charlton (billy)]

Found it. Please mark this bug "invalid". The problem lies in the Xming win32 X server, which for some reason can connect to Gutsy via XDMCP, but not to Hardy. When I use XDMCP from a real Linux box, I can log in normally.

Not sure why it doesn't work with Hardy but I can't worry about it.

[Kuropka (d2)]

I am using Cygwin/X on Windows to remotly login to my computer using Ubuntu 8.04 and have the same issue. The interesting thing is: it worked with the previous Ubuntu Version without problems. So maybe this bug should be reopened since it seems to be Ubuntu related.

[kakaz (kakazo2)]

I try different options, and found the proper one, at least for Xming X server on WinXP: You have to enable 16001 port on Windows firewall. I enabled both UDP and TCP 16001 and after few seconds orange background disappears and desktop appears. I also remove sound modules from memory on Linux box,and disable ESD but I believe that this has no influence on this issue.