Bug 448195 - gdm takes too much time to start loading GNOME/KDE
gdm takes too much time to start loading GNOME/KDE
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
i686 Linux
low Severity high
: ---
: ---
Assigned To: jmccann
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-05-24 06:00 EDT by Syam
Modified: 2015-01-14 18:21 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-14 14:01:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/var/log/messages on booting to runlevel 3 (35.00 KB, text/plain)
2008-05-27 22:19 EDT, Syam
no flags Details
/var/log/messages after telinit 5 (37.48 KB, text/plain)
2008-05-27 22:20 EDT, Syam
no flags Details
/var/log/messages after KDE is up and running (38.93 KB, text/plain)
2008-05-27 22:21 EDT, Syam
no flags Details
/var/log/messages after logging out of KDE and starting GMONE as root (44.69 KB, text/plain)
2008-05-27 22:21 EDT, Syam
no flags Details
/etc/pam.d/system-auth (890 bytes, text/plain)
2008-05-27 22:22 EDT, Syam
no flags Details
/etc/hosts (191 bytes, application/octet-stream)
2008-05-28 11:33 EDT, Syam
no flags Details
/etc/nsswitch.conf (1.66 KB, text/plain)
2008-06-09 21:37 EDT, Syam
no flags Details

  None (edit)
Description Syam 2008-05-24 06:00:57 EDT
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
Actual results:
GNOME/KDE starts loading after 15-20 seconds.

Expected results:
Desktop environment loaded in reasonable amount of time.
Comment 1 Syam 2008-05-25 22:45:21 EDT
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.
Comment 2 Ray Strode [halfline] 2008-05-26 18:16:41 EDT
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 ?
Comment 3 Syam 2008-05-27 22:18:56 EDT
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.
Comment 4 Syam 2008-05-27 22:19:50 EDT
Created attachment 306873 [details]
/var/log/messages on booting to runlevel 3
Comment 5 Syam 2008-05-27 22:20:32 EDT
Created attachment 306874 [details]
/var/log/messages after telinit 5
Comment 6 Syam 2008-05-27 22:21:04 EDT
Created attachment 306875 [details]
/var/log/messages after KDE is up and running
Comment 7 Syam 2008-05-27 22:21:46 EDT
Created attachment 306876 [details]
/var/log/messages after logging out of KDE and starting GMONE as root
Comment 8 Syam 2008-05-27 22:22:09 EDT
Created attachment 306877 [details]
Comment 9 Ray Strode [halfline] 2008-05-28 10:11:09 EDT
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 ?
Comment 10 Syam 2008-05-28 11:32:48 EDT
/bin/hostname gives 'zig' (without the quotes, of course..)
Thanks for the help..
Comment 11 Syam 2008-05-28 11:33:29 EDT
Created attachment 306942 [details]
Comment 12 Syam 2008-05-30 23:14:34 EDT
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?
Comment 13 Syam 2008-06-07 13:04:04 EDT
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.
Comment 14 Ray Strode [halfline] 2008-06-09 11:23:58 EDT
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.
Comment 15 Syam 2008-06-09 21:37:19 EDT
Created attachment 308760 [details]
Comment 16 Syam 2008-06-09 21:39:47 EDT
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.
Comment 17 Ray Strode [halfline] 2008-06-10 00:04:04 EDT
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)
Comment 18 Ray Strode [halfline] 2008-06-10 00:06:07 EDT
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
Comment 19 Syam 2008-06-10 13:08:45 EDT
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.
Comment 20 Syam 2008-08-19 21:28:12 EDT
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.
Comment 21 Bug Zapper 2009-06-09 21:08:18 EDT
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: 
Comment 22 Syam 2009-06-09 21:38:50 EDT
This bug doesn't exist with Fedora 10. So, I guess it's gonna be dead.
Comment 23 Bug Zapper 2009-07-14 14:01:51 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.