Red Hat Bugzilla – Bug 448195
gdm takes too much time to start loading GNOME/KDE
Last modified: 2015-01-14 18:21:22 EST
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
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
GNOME/KDE starts loading after 15-20 seconds.
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]
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: gethostby*.getanswer: asked for
"", got "."
May 27 20:33:26 zig pulseaudio: 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]
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]
Thanks for the reply. Here's the output of rpm -qf /lib*/libnss_* | sort -u
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:
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.