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): How reproducible: Always 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. Additional info:
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 : http://bugs.kde.org/show_bug.cgi?id=40153 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 done 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