Recently David shared some issues with starting
Trinity. In his case the probable cause seemed to be stale profile cache file or profile cache files using the old prefix names.
Today I stumbled across a way to stall the session
startup. I changed some settings in KControl.
What caught my eye with this bug is the xsession log
error, which David saw as well:
ksmserver: '<wm>' missing. ksmserver: Use --help to get a list of available
command line options.
I traced the cause to these lines in my profile
twinrc:
[ThirdPartyWM] WMAdditionalArguments= WMExecutable=twin
Those lines and group do not exist in a twinrc backup
file and is the only difference between the files.
This is not a hard freeze. Trinity exits gracefully
back to the command line, which is how I start X/Trinity.
The problem is with tdeinit_phase1. I commented out
that command in starttde. I successfully substituted all of the following:
kwrapper ksmserver --windowmanager twin
--windowmanageraddargs ""
kwrapper ksmserver --windowmanager twin
kwrapper ksmserver
Looking at the tdeinit_phase1 source code, I see that
when WMExecutable is undefined/empty then tdeinit_phase1 defaults to "kwrapper ksmserver." As my previous twinrc contained no ThirdPartyWM group in twinrc, that is how tdeinit_phase1 always started.
When I changed some settings in KControl to cause
twinrc to update with including the ThirdPartyWM group, tdeinit_phase1 instead starts with "kwrapper ksmserver --windowmanager %1 --windowmanageraddargs %2."
Changing the twinrc WMAdditionalArguments to
WMAdditionalArguments=--lock allowed Trinity to start using tdeinit_phase1.
I think the solution then is to add the following
condition test to tdeinit_phase1:
else if (wmArguments == "") { return_code =
system((TQString("kwrapper ksmserver --windowmanager %1").arg(wmToLaunch)).ascii());
Comments?
Darrell
This is starting to make sense. On the session before I started experiencing crashes with starttde, I had updated the background to be displayed in kcontrol -> login manager. I suspect what you were able to traceback more thoroughly that I was the root cause of the crashes I experienced as well. Good catch!
I have a patch that I ask somebody either test or provide a peer review signoff.
I added new code, albeit only a single "else if" test.
I have tested the patch in both a VM and physical machine. No more halts in the session startup.
Here is the patch:
http://humanreadable.nfshost.com/trinity/patches/tdebase/tdebase-tdeinit_pha...
If testing the patch then do so like this:
* Before patching and updating tdebase, start a Trinity session. * Open KControl, Appearance & Themes, Window Decorations. * Toggle any nominal setting and select the Apply button. * Exit the session. * Login to start a new session. * Verify the session stalls and won't start. * Restore twinrc: edit twinrc config file and delete the group section "ThirdPartyWM." * Login to verify that once again Trinity starts. * Log out. * Install the patched tdebase. * Start the session and repeat the KControl exercise. * Exit the session. * Start the session. * Verify Trinity now starts without stalling.
Thanks!
Darrell