ksplash hangs on initializing system services sometimes if "Start with an empty session" is enabled

Bug #46682 reported by Mark Jenkins
Affects Status Importance Assigned to Milestone
kdebase (Ubuntu)
Fix Released
Nominated for Dapper by Mark Jenkins

Bug Description

Binary package hint: ksplash

ksplash in Dapper is hanging sometimes at "initializing system services".

This only happens if "Start with an empty session" from the Session Manager settings (in KDE Components in System Settings) is the choice for "On Login". The hang can be skipped by clicking. The underlying startup process continues as normal during the hang, if you wait long enough through the hang and then click, a fully ready desktop environment will be ready. Top doesn't reveal any abnormal cpu or memory usage.

The hang occurs more often when my cpu is clocked at 600MHz, and less often at 1.5GHz. I haven't seen it happen when using KDM instead of GDM at the higher clock rate. At the lower clock rate it doesn't matter which display manager is being used. The bug is potentially a race condition.

The hang ends after about 60 seconds on both cpu speeds. The icons after "initializing system services" don't light up after the hang ends, the desktop just appears.

I've seen this bug on multiple computers with different graphics chipsets, in all cases using only the free graphic drivers from main. I've been able to replicate this on new clean accounts with only the "On Login" session restore setting changed. I've seen this happen to both the kde default splash and kde wheat. In all cases the latest packages from Dapper were in use.

Sometimes a small white rectangle appears in the top left corner right after the hang begins.

At high clock rates I have sometimes seen the desktop that you would expect to see after the splash screen appear first, followed by the hanging splash screen.

Revision history for this message
Mark Jenkins (mark-parit) wrote :

More information.

If I take a new clean account and change to the "Start with an empty session" setting there is no problem. If I logout, login, change back to the default of restoring the saved session, logout, login, change back to "Start with an empty session", logout, and login the problem appears.

Revision history for this message
Mark Jenkins (mark-parit) wrote :

My above comment is wrong. I've since been able to create a fresh account, login, change the setting, log back in and experience the problem.

Revision history for this message
Mark Jenkins (mark-parit) wrote : Patch to startkde to make race condition more obvious

This is a patch to /usr/bin/startkde . It makes it much easier to reproduce this bug. The patch calls ksplash with nice 19 and comments out a sleep command. This creates a stronger bias for ksplash to lose the race more often.

Revision history for this message
Mark Jenkins (mark-parit) wrote :

A further comment on my anti-patch. The "On Login" session setting doesn't actually matter, the default just makes it less likely that this bug will occure. With the patch applied to startkde this bug is also reproducable under the default settings.

Revision history for this message
Mark Jenkins (mark-parit) wrote : patch to fix race condition due to too early fork in ksplash

A patch that closes this bug.

ksplash backgrounds itself early on so the startup process in /usr/bin/startkde can continue. ksplash is doing this too early, and it leads to a race condition where if ksplash loses the race, the programs started by startkde will do their work, send a signal to ksplash, and the signal will fail to be used due to ksplash not being ready for it yet. After losing the race ksplash will hang, waiting for fellow racers who are long gone.

I believe this patch moves the backgrounding forward to a point where ksplash is guaranteed to be ready for these signals. I have tested it with the above anti-patch applied, and without. There is no noticeable performance loss in the startup process.

Revision history for this message
gmax.jp (gmax-jp) wrote :

Using default ksplash screen, I've experienced the similar problem on my machine (Celeron D 2.4GHz w/512MB). kubuntu dapper upgraded to KDE 3.5.4.

Changing default ksplash to MoodinKDE reliefed the bug.

Any one who met same problem ?

Revision history for this message
Yuriy Kozlov (yuriy-kozlov) wrote :

I couldn't reproduce this on kubuntu dapper with kde 3.5.3 on a 900mhz machine.

Revision history for this message
Anthony Mercatante (tonio) wrote :

Fixed with latest kdebase upload.
Thanks to Mark Jenkins for the patch !

Changed in kdebase:
status: Unconfirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers