Description of problem: gdm takes too long to start loading GNOME/KDE. After I enter the login details and hit Enter, it takes about 15-20 seconds (yes, that's way too long) before GNOME or KDE starts loading. During that time, only the gdm background image is displayed. Could this be a PulseAudio issue (that's the only thing I can think of!)? Is there any way of finding out what's happening during this time? I talked to a friend of mine, and for him too it takes around 10 seconds. Steps to Reproduce: 1. Boot to initlevel 5 2. Type in the login details in gdm 3. Hit enter key Actual results: GNOME/KDE starts loading after 15-20 seconds. Expected results: Desktop environment loaded in reasonable amount of time.
I measured time with a wall clock. It *always* takes 27 seconds for GNOME or KDE to start from gdm. I tried as root and as a normal user. It always takes 27 seconds. I tried switching to runlevel 3 (telinit 3), and then a startx. It takes about 3s for X to start and in about 7seconds, GNOME is up and running. So, the problem is only if I login using gdm. I'll try to switch to kdm and update the results.
Interesting. GDM shouldn't be doing anything special that would take a long time. If KDM is quick to, we should try to figure out what's going wrong. Out of curiosity, if you turn Enable=true in the [Debug] section of /etc/gdm/custom.conf does /var/log/messages show anything interesting? It could be something to do with your PAM configuration. Can you attach /etc/pam.d/system-auth ?
I haven't yet figured out how to switch to kdm. Giving DISPLAYMANAGER=KDM in /etc/sysconfig/desktop doesn't work. I still end up with gdm. Anyway, I set Enable=true in [Debug] of /etc/gdm/custom.conf and I'm attaching my /var/log/messages for different scenarios. I switched default runlevel to 3. I haven't had time to go through the files in detail. Will do it today.
Created attachment 306873 [details] /var/log/messages on booting to runlevel 3
Created attachment 306874 [details] /var/log/messages after telinit 5
Created attachment 306875 [details] /var/log/messages after KDE is up and running
Created attachment 306876 [details] /var/log/messages after logging out of KDE and starting GMONE as root
Created attachment 306877 [details] /etc/pam.d/system-auth
So shortly after starting your session we see this in the log ay 27 20:32:56 zig gconfd (syamcr-2860): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration source at position 2 May 27 20:33:17 zig gdm-session-worker[2535]: gethostby*.getanswer: asked for "", got "." May 27 20:33:26 zig pulseaudio[3211]: pid.c: Stale PID file, overwriting. There's a good 20 seconds between gconfd starting and the session worker given a cryptic message about the network. I don't think the session worker calls gethostbyname on its own, so I suspect a pam module is calling it and it's blocking. will need more investigation, but in the mean time can you attach your /etc/hosts file and the output of /bin/hostname ?
/bin/hostname gives 'zig' (without the quotes, of course..) Thanks for the help..
Created attachment 306942 [details] /etc/hosts
Additional info: Even if I type a wrong password, it takes around 22 seconds for GDM to tell me that it's wrong! Any updates on this bug?
I switched to KDM and it's OK. After I enter the login details, it starts loading KDE in abt 7 seconds. So I guess the problem is with GDM.
Can you attach your /etc/nsswitch.conf and the output of rpm -qf /lib*/libnss_* | sort -u ? I don't think the problem is with GDM (although I'm not sure). It's doing a name lookup and somewhere in the guts of nss / libc it's blocking for 10 seconds and spewing to syslog.
Created attachment 308760 [details] /etc/nsswitch.conf
Thanks for the reply. Here's the output of rpm -qf /lib*/libnss_* | sort -u glibc-2.8-3.i686 nss_db-2.2-40.fc9.i386 samba-common-3.2.0-1.rc1.14.fc9.i386 samba-winbind-3.2.0-1.rc1.14.fc9.i386 My machine config: A single machine with static IP, connected to one DSL modem (router). No NIS.
So I talked with Uli (the glibc maintainer) and he said this could be explained by a bug in libresolv's new implementation of getaddrinfo. I'm not sure where in the login stack we're calling getaddrinfo, but I presume it's in a pam module or nsswitch module. Anyway, Uli mentioned that Peter Jones ran into this issue and is going to file a bug with more details. He suggests we wait for that bug to get filed and fixed and confirm it's the same issue. (add peter to this bug)
Oh, one more thought. You said that you don't get the delay with KDM. One big difference between the pam stacks of GDM and KDM is that GDM will try to unlock the gnome-keyring with your login password to prevent you from having to type it at login. If that pam module is to blame, a workaround would be to put a # in front of the two lines that mention pam_gnome_keyring.so in /etc/pam.d/gdm
A ray of hope? Thanks a lot. But I did try out what you suggested in comment #18. But that didn't work. GDM still took exactly 27 seconds! I'm back to KDM.
Is it possible that it has something to do with SCIM? I re-installed Fedora 9, and gdm was working OK. Now it's back to the behaviour reported here, and I think I had installed SCIM before it happened.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. 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 '9'. 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 9'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 9 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This bug doesn't exist with Fedora 10. So, I guess it's gonna be dead.
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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.