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. Reproduce Procedure: 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): scim-1.4.2-0
http://people.redhat.com/wtogami/archive/2005/bootchart-unset.svgz bootchart revealing that scim is causing the huge delay during bootup. http://people.redhat.com/wtogami/archive/2005/bootchart-set-simple.svgz 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 of GTK+.
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.