freezes for 15 seconds with "throbber started" before timing out
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
xsplash (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: xsplash
After upgrading to karmic, I found that logging in took 15 seconds longer than it previously had. The 15-second delay does not depend on the choice of desktop session. E.g., it takes the extra 15 seconds even if you're logging in to an xterm failsafe session. By careful comparison against wall-clock time, I was able to find that the 15-second delay coincides with the following in /var/log/
[09:52:
[09:52:
The "throbber started" message occurs at the beginning of the delay, and the "timeout" message at the end.
This appears to be related to, but not the same as, these bugs: https:/
I'm not sure, but my guess is that xsplash expects to receive a signal from Gnome telling it that it's started up. I'm guessing that other desktops besides Gnome (e.g., fluxbox or the xterm failsafe session) do not provide such a signal, so xsplash hangs up the login process for 15 seconds waiting for the signal.
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 9.10
Release: 9.10
Codename: karmic
$ uname -a
Linux rintintin 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 17:01:44 UTC 2009 x86_64 GNU/Linux
$ apt-cache policy xsplash
xsplash:
Installed: 0.8.5-0ubuntu1
Candidate: 0.8.5-0ubuntu1
Version table:
*** 0.8.5-0ubuntu1 0
500 http://
100 /var/lib/
0.8.4-0ubuntu1 0
500 http://
I located the place in the source where this is happening. There is a function in xsplash.c called "temporary_ hack_for_ initial_ fade." Well, I guess the name of the function says it all. The callback to temporary_ hack_for_ initial_ fade is set in main(). Note that the 15 is hardcoded in two different places:
static guint timeout = 15;
"Timeout (in seconds - 15s by default) ", NULL