If scim is installed, rhgb gets stuck for up to 1 minute and 42 seconds before
doing anything during bootup. This problem manifests due to this bug in scim,
and also the unpredictable behavior of what GTK+ immodule is chosen when
GTK_IM_MODULE is unset.
1. Install scim on RHEL4, FC3, FC4, or FC5.
2. Boot with rhgb in the kernel boot options.
3. Watch as X is stuck for up to 1 minute and 42 seconds.
If you export GTK_IM_MODULE=gtk-im-context-simple in rc.sysinit before it runs
rhgb, it works around this problem by avoiding loading of scim immodule, but
this of course is not a good solution.
Version-Release number of selected component (if applicable):
bootchart revealing that scim is causing the huge delay during bootup.
export GTK_IM_MODULE=gtk-im-context-simple in rc.sysinit before rhgb is launched
hides the problem, as would the proposed solution to Bug #167090.
Bug #167090 is the GTK_IM_MODULE problem, when solved will unfortunately only
hide this problem. This problem itself must be investigated in order to be sure
it wont cause defects during regular desktop operation, firstboot, or other uses
Warren commented the other day that this may be due to scim being
launched while the root filesystem is still mounted read-only.
Added a patch in scim-1.4.2-2 to set the gtk immodule lang list empty.
Actually making the lang list empty is the solution that we agreed upon for Bug
#167090. That change does effectively negate the huge rhgb delay problem which
was probably our most serious bug.
This bug is a different issue where scim gets stuck for a long time if it cannot
create its sockets. I think we should make scim fail immediately rather than
wait such a long time. Resetting to FC5Target, this is a lower priority issue now.
Hmm... I think I was wrong about r/o filesystem being the cause of this problem.
By the time rhgb runs here, the root is already remounted r/w. While we are
avoiding this problem with the immodule language removal, we should still figure
out the cause.
A more recent version of SCIM no longer enables IM in GTK+ password dialogs, so
there are now two things preventing this from happening in gnome-ssh-askpass. I
suppose this is only a symptom of the debug prints going to stdout combined with
the crap redirection used by askpass. Hopefully nothing else is affected by
this. So closing...
oops, the password dialog thing was meant for Bug #168654. This might still be
a problem... retesting.
Closing for now. Please reopen if the problem occurs again.