Red Hat Bugzilla – Bug 447082
Applications sometimes take anormaly long time to launch
Last modified: 2018-04-11 03:38:05 EDT
Description of problem:
Sometimes applications take 30+ seconds to launch.
Version-Release number of selected component (if applicable): 9
Steps to Reproduce:
1. Launch an application
Actual results: Really long waiting time
Expected results: No waiting time
When using my computer, sometimes it seems to switch into a mode where it takes
a very long time to launch anything. It then stays in it for some times, then
switch back, much to my relief.
The problem only seems to affect gnome/gtk apps : gnome-terminal, emacs, firefox
are affected, xpdf, emacs -nw are not.
I attach the output of strace emacs 2> log, the problem seems to be with
Configuration : (mostly) vanilla F9
Created attachment 305814 [details]
strace emacs 2> log
I have no idea, what to think about this bug. So, let's collect some
information. Please attach your X server config file (/etc/X11/xorg.conf) and X
server log file (/var/log/Xorg.*.log) to the bug report as individual
uncompressed file attachments using the bugzilla file attachment link below.
Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
Created attachment 305963 [details]
I probably should have mentionned I'm using nvidia's beta driver. It's entirely
possible that this bug is nvidia's fault and that I'm reporting in the wrong
Anyway, here are the files you requested. I could try to run without any
xorg.conf, but I probably wouldn't be able to reproduce the bug (it happens
rarely, never happened to me again since I filed this bug report)
Created attachment 305964 [details]
Created attachment 305966 [details]
OK, I admire your honesty to admit using nvidia binary-only driver although you
may have some hints about consequences ;-). No, I mean seriously -- we cannot
support ndivia binary-only drivers -- we don't have neither source code nor
sufficient documentation for them, so we cannot fix them when they are broken.
And we have plenty of mysterious bugs which just vanished once the normal
(arguably suboptimal) open source drivers were used.
Until you are able to reproduce this using drivers provided with Fedora (or any
other open source drivers, but I don't know about any) and reopen this bug with
the additional information, I have unfortunately no other choice than close this
bug as CLOSED/CANTFIX.
I was able to reproduce this bug under the free drivers nv.
The strace is the same, the symptoms are the same.
I'm using a (nearly, only modifications are for the touchpad) default xorg.conf.
It seems the bug is network-related, since all the times (that I know of) that I
triggered it, it was after disconnecting/reconnecting from the (wired) net.
However, the app is clearly waiting for something X-related, and gnome-terminal
(which, I hope, has nothing to do with net) is affected.
I have a similar situation that could be related.
When running applications on a remote X-server (Cygwin), some applications are
extremely slow on FC9. These include Firefox, Galeon and Evince. However,
unlike Antoine, emacs is not included in the list of misbehaving apps. Unlike
the other apps, gnome-terminal presents a window immediately, but takes a long
time for the prompt to appear.
These apps work fine from FC6 on the same X-server. I did not notice a
problem on FC8, but only ran that for a short time so I might have missed it.
They also work fine on FC9 from the console.
FC9 on Core2 Duo patched up to date as of this morning - 17 Jun.
Some applications would behave in similar ways when name resolution is broken. Might be a good idea to check whether this is the cause by checking how they behave when network interfaces are completely down or by verifying that the host names in question resolve correctly both in forward and in reverse lookups.
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:
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.