Red Hat Bugzilla – Bug 66717
Multiple sessions from different displays confuses dcop/klauncher
Last modified: 2007-04-18 12:43:10 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)
Description of problem:
Starting another KDE session from another X-terminal confuses KDE on the
previous sessions from different X-terminals. Results in 'KLaucher could not be
reached via DCOP' -message.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start a KDE session for user nnn from console
2. Start another KDE session for user nnn from a remote X-terminal
3. Try to start an application (say, a konsole window) from console session
(the first session)
Actual Results: Error message 'KLaucher could not be reached via DCOP', and
possibly later another message 'There was an error setting up inter-process
communications for KDE. The message returned by the system was: Could not open
network socket. Please check that the "dcopserver" program is running'.
The second session works as expected (actually, seems like the last session
started always works, the other don't).
Expected Results: Applications start up as expected.
In my experience, this is simply a KDE limitation (1 KDE sesion per user per
machine), and has been there since the 2.x days. You CAN have multiple
sessions on the same machine for different users and/or have multiple sessions
for the same user on difference machines.
Just upgraded to RH9, and found out the same problem is still there...
Did some googling, and found :
So, it seems this is a RedHat -specific bug... Modified /usr/bin/startkde
incorrectly deletes all socket-files used by other dcop processes, thus making
it impossible for existing sessions to communicate with the dcop process...
Commenting out the following lines helps :
rm -f ~/.DCOPserver-`/bin/hostname`_$DISPLAY
for i in /tmp/.ICE-unix/* /tmp/.ICE-unix/.*; do
[ -O $i ] && rm -f $i
Note that I also commented out the first "rm" (wasn't commented in the kde
bugreport). This is because /bin/hostname always returns X client hostname, not
the display (X server) name. And in my opinion, what we want to delete is the
file that refers to the display we're using...
So, if old (killed/died) session cleanup is needed, more checks are required.
For now i'm happy to leave some orphan files behind...
This can probably be closed, as I'm pretty sure this has been fixed in
development for some time.
it's fixed in current fedora