Bug 427737 - gnome very slow to login/start
gnome very slow to login/start
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
i686 Linux
low Severity high
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-01-07 05:40 EST by morgan read
Modified: 2017-10-06 14:20 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-09 00:43:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mleitner: needinfo-

Attachments (Terms of Use)

  None (edit)
Description morgan read 2008-01-07 05:40:44 EST
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
sometimes not.

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):
v 2.20.2

How reproducible:
Seems fairly consistent, but not completely so...

Steps to Reproduce:
1. Login, perhaps logout and login again to clear the problem
Actual results:
Gnome based programmes seem to take overly long to start

Expected results:
Programmes start cleanly without undue delay

Additional info:
Happy to provide any info needed, looking for pointers...
Comment 1 Toshio Ernie Kuratomi 2008-01-07 11:26:16 EST
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.
Comment 2 Toshio Ernie Kuratomi 2008-01-14 09:02:28 EST
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[1]_ 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.

_[1]: https://www.redhat.com/archives/fedora-devel-list/2008-January/msg01286.html
Comment 3 morgan read 2008-01-14 22:19:33 EST
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.)

Any thoughts?

Comment 4 Toshio Ernie Kuratomi 2008-01-16 14:40:38 EST
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.
Comment 5 Dan Williams 2008-01-16 14:47:39 EST
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.
Comment 6 morgan read 2008-01-17 03:48:19 EST
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:-)
Comment 7 morgan read 2008-01-23 15:49:04 EST
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.
Comment 8 Earl Pomeroy 2008-01-27 20:08:34 EST
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.
Comment 9 morgan read 2008-01-29 04:01:12 EST
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...
Comment 10 Marc Linde 2008-03-10 19:08:44 EDT
Hello, since the kernel update 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 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.

Comment 11 Salih Şen 2008-05-23 19:53:51 EDT
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 So it looks like this now:
# Do not remove the following line, or various programs
# that require network functionality will fail.	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.
Comment 12 morgan read 2008-05-26 04:45:45 EDT
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...
Comment 13 Bug Zapper 2008-11-26 04:19:42 EST
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: 
Comment 14 Bug Zapper 2009-01-09 00:43:37 EST
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.

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