Red Hat Bugzilla – Bug 427737
gnome very slow to login/start
Last modified: 2017-10-06 14:20:22 EDT
Description of problem:
Gnome is very slow to respond following login, this seems to be across all gnome
based applications - eg evolution, gedit (other apps like firefox & t'bird don't
exhibit the symptoms). They take something close to 40-50" to load, often
showing activity, then nothing, then activity again. If I log out and log back
in again then the symptoms go away, but often in this case the login screen
hangs at login for 40-50".
This is very amorphous and difficult to pin down. The symptoms have been
displayed since I moved to f8. I was expecting a fix fairly quick as it's very
noticeable, but nothing yet - so here's the bug...
Something that may be a clue is that, there may be some correlation with gnome
taking a long second time login (and fixing the slowness) and NetworkManager not
requiring to be logged in again. NetworkManager's behavior seems to be
inconsistent - sometime requiring a login on the second time login, and
Please re-assign if I've not got the correct component - the problem seems to be
with gnome. Sorry if this seems like a bit of fishing trip, but there's
something going on.
Version-Release number of selected component (if applicable):
Seems fairly consistent, but not completely so...
Steps to Reproduce:
1. Login, perhaps logout and login again to clear the problem
Gnome based programmes seem to take overly long to start
Programmes start cleanly without undue delay
Happy to provide any info needed, looking for pointers...
gnome-common is an actual package that is used to help develop gnome
applications so this will need to be filed somewhere else eventually. I'd try
emailing one of the lists (fedora-list or fedora-devel-list) or asking on IRC
(#fedora) to try to narrow down your problem before posting, though, as the
current information is too vague for me to decide where it should go.
This appears to stem from the fact that Fedora stopped using readahead for
Fedora 8. In F-7 and below, readahead would run during boot and read programs
into memory while the system was supposedly not doing other disk io.
Benchmarking of actual boot time during the F8 development cycle showed that
total boot time was suffering because of readahead instead of improving so it
was disabled by default.
There is presently a discussion on fedora-devel-list_ about this issue. You
might want to join that and help move things forward.
Closing as this seems to be an overall problem that needs to be solved with a
bug/RFE outside of the gnome stack. Feel free to reopen if you feel differently.
You may be right, I'll have a look over that thread.
But, I've been observing the behaviour a little more closely:
I seems that if I fill in the password prompt for gnome-keyring (required for my
NetworkManager managed wireless networks) as soon as it appears - before the
panel-apps have finished loading - then this slowness is present in gnome apps.
(I've been using gnome-terminal to check, it loads immediately but if this
slowness is present it'll take more then 40 seconds to load.) But, if I wait
until all the panel-apps have loaded and the system seems to have settled before
filling in the password prompt, then there is no slowness.
Which leads me to wonder if the problem might be with gnome-keyring or perhaps
(Yeah, I've looked over that thread - it seems to be about booting only. This
problem continues for ever, until I log out and log in again - unless I've
avoided it, see above. Also, it really seems to be limited to gnome apps:
T'bird, OOo & Firefox don't exhibit the symptoms - I use them a lot.)
Yes, that sounds like a different issue. Reassigning to NetworkManager for now
but there will probably need to be more troubleshooting to figure out where the
slowdown is coming from.
Try to get backtraces on the apps that are slow to load. Does one of the top
functions indicate ICE? This may be X session management being stupid again
about hostname lookups.
I've done backtraces once before (rdiff-backup I think) and I've had a browse
over this: http://fedoraproject.org/wiki/StackTraces .
From what I know (not a lot) I need to have an app crash to generate one? No
apps seem to be crashing. Is there something I can do to create one otherwise?
Can you give me a bit more rope on that second question please:-)
Installed valgrind; did some test traces with it: went to reproduce the error,
went to reproduce the error again, and again...
Oh well, seems I didn't wait long enough before reporting this bug - seems to
have resolved itself...
Guess it can be closed, I'll re-open if it comes back.
Thanks for listening.
This sounds exactly like the problem I still am experiencing. The problem occurs
when I move my laptop between networks (work and home). The first time I login
to a "new" network, Gnome apps take a long time to start. If log out of the
session and log right back in and all apps will start immediately. As long as
I'm on that network, rebooting and logging back in work fine. I figured it has
something to do with NetworkManager, DHCP info, and Gnome getting momentarily lost.
I did not have this problem in F7.
Hmm, that's very interesting. As I said, the problem seemed to clear itself.
BUT, I was moving my machine between work and home on a daily basis exactly as
Jon describes and have recently stopped... I'll start moving it around again
and see what happens...
Hello, since the kernel update 184.108.40.206-12 in Fedora8 on may Intel Centrino
1,73ghz notebook , intel chipset, ati x700 mobilty and my atheros 5212 card
gnome is incredibly slow.
I tracked the problem down to Networkmanager.
I tried the ath5k and the 0.9.4 madwifi driver, every time the NetworkManager
Daemon starts the system slows down. Sometimes when gnome starts and the
Networkmanagerapplet comes up the System freezes. In the cases it's not freezing
the system is so slow that I can't work with it.
With the 220.127.116.11-137 anything works like a charm.
I try to track the problem .. it's a little bit hard because the system is very
slow and the freezes happen very often.
I am not sure if it is exactly the same problem but I experienced slow gnome
applications problem as well. It occured after disabling NetworkManager and
enabling network deamon.
Solution was adding my hostname to /etc/hosts file at the end of the line starts
with 127.0.0.1. So it looks like this now:
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost.localdomain localhost darkstar
::1 localhost.localdomain localhost6 localhost
Again I am not sure if this is the same problem but symtoms are the same.
I recently had to regularly move mine to and from work again - the problem seems
to have resolved itself... I didn't notice any slowdown anymore. Not very
helpful for those still experiencing something...
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8. 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 '8'.
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 8'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 8 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:
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 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.