Header Shadow Image


Fedora & KDE: ERROR: Couldn’t attach to DCOP server!

DCOP server is essentially communication software used by various Linux systems to allow applications to talk to each other.  For example, copying and pasting from kword to say firefox would occur through klipper (KDE clipboard) currently and the way the copied data moves between these applications is DCOP.  More recently, DCOP has been started to be phased out in favour of DBUS, a new messaging system implemented in KDE 4.X (Recently 4.0, 4.1, 4.2). (While digging for a solution here, I had a stab at using DBUS however according to this article, konsole hasn't yet been updated to use DBUS)  This particular change occurred more recently and prominantly between Fedora 8 to Fedora 9 upgrade discussed in another article here.  One of the issues to this problem is that in the process of moving from KDE 3.X to KDE 4.X is that the dcopserver is no longer turned on by default.  Unfortunately, applications such as konsole have not yet been udpated to use DBUS and so scripting these applications as one would normally do using DCOP, no longer work and functionality like renaming tabs in konsole dynamically therefore no longer work either using traditional methods.  Below is how to go about resolving a part if not all of the issues related to it and how we can reenable it to reduce errors between old applications on a distribution.

PROBLEM

You may notice the problem below when running some older applications:

$ dcop
DCOPClient::attachInternal. Attach failed Could not open network socket
DCOPClient::attachInternal. Attach failed Could not open network socket
ERROR: Couldn't attach to DCOP server!

$

or

$ dcop –user root
ERROR: No active KDE sessions!
If you are sure there is one, please set the $DCOPSERVER variable manually
before calling dcop.
$

or

klauncher could not be reached via DCOP

when clicking certain links such as help menus under Fedora 8 or older applications that have not yet been updated to use DBUS.

SOLUTION

There are several possible solutions to this listed below:

  • Check for and delete old stale files from a previous DCOP run that may have crashed and left the system in an inconsistent state (First check if dcop server (dcopserver) is running by issuing ps axfo pid,ppid,user,cmd=|grep dcop): 

    $ ps axfo pid,ppid,user,cmd=|grep dcop
    25111 25082 root          \_ grep dcop
    $

    /root/.DCOPserver_lhs.localhostservers__0
    /root/.DCOPserver_lhs.localhostservers_:0
    /tmp/.ICE-unix/dcop10328-1227569420
    /root/.ICEauthority
    (NOTE: Files on your system may not be exactly as shown.  Replace /root with your home user folder if using a non previlidged user) accounts.

    Then restart KDE and the X Windows desktop by either rebooting or issuing init 1 at the command prompt then init 5 again once in runlevel 1 to return to the KDE desktop.  Use command runlevel to find out which run level you are currently in.  The above files should be recreated once you restart and DCOP may return to a working status once above is done.  If not, continue below.
     

  •  Run /usr/bin/kdeinit to restart the dcopserver and implement the line at end of /usr/bin/startkde so it starts when /usr/bin/kdeinit4 starts again on subsequent reboots.  You can also optionally add this entry:

    */10 * * * * nice -n 10 if ! ps -ef|grep "dcopserver –nosid"|grep -v grep >/dev/null 2>&1; then /usr/bin/kdeinit; fi

    to your crontab file using $ crontab -e to ensure in case dcopserver stops (ie: no dcop server apps running), it will be restarted.

DETAILS

How to go about resolving this is a bit more complex but the details are important for consideration.  The initial issue surfaced earlier when running konsole which I had configured to dynamically change the tab text in konsole reflecting what I was doing.

The first thing in my investigation was to run the dcop executable to see what was going on.  This was the root command with which I used to use to rename tabs with.  This naturally produced the above error message and exited without doing much of anything else.

Next I set out to find the dcop server.  After some searching, I used the below command which provided me with a list of all executables related to dcop:

$ locate dcop|grep "/bin/"
/usr/bin/dcop
/usr/bin/dcopclient
/usr/bin/dcopfind
/usr/bin/dcopidl
/usr/bin/dcopidl2cpp
/usr/bin/dcopidlng
/usr/bin/dcopobject
/usr/bin/dcopquit
/usr/bin/dcopref
/usr/bin/dcopserver
/usr/bin/dcopserver_shutdown
/usr/bin/dcopstart
/usr/bin/kdcop
$

which told me a bit more as to what I needed to do.  Two application stood out: dcopserver and dcopstart.  Reading a bit more it was clear I needed to work with dcopserver.  Simply running it resolved the issue with the first error but I still go the third error listed above so I wasn't convinced that was the right thing to do as it didn't look to have been started properly.  After all, typing dcopserver –help produced a list of options that could be run and above web link listed even more hidden options that my man pages didn't have (Apparently poor linux documentation with regards to dcop* files).  What I didn't know is how to properly start dcopserver.  Did I need to use any of the options to ensure proper startup and configuration?  Renaming tabs using dcop in konsole still didn't work so it seams something was missing.  Checking I see dcop binary no longer produced the error seen above:

$ dcop
$

So it appears issue is resolved.  Next I checked konsole and noticed that the KONSOLE_DCOP variables are missing following the above post for changing the tab titles accordingly:

$ env|grep KONSOLE_DCOP
$

However, they should look similar to what we see below which would point to the konsole instance running which could then be manipulated to change tab titles:

KONSOLE_DCOP=DCOPRef(konsole-2935,konsole)
KONSOLE_DCOP_SESSION=DCOPRef(konsole-2935,session-3)

One could set the above using above lines using the instructions found here with regards to terminal emulators and scripting them.  One of the things I checked is how dcopserver is running using ps axfo pid,ppid,user,cmd=|grep dcopserver which produced the below output:

$ ps axfo pid,ppid,user,cmd=|grep dcopserver
25760 23268 root      |   \_ grep dcopserver
25210     1 root     dcopserver
$

This told me that dcopserver was started without any parameters, no surprise here.  This is important and also that running dcop produced no results.  So after some time reading up on the dcopserver command including proper options dcopserver could have been used with, searching both in /var/log files  and config files in /etc/, produced little information.  I then tried another application from above list: kdcop.  Running the application this time started up a KDE DCOP application as expected (the k in front of dcop) and this too showed no applications listed so it looks like no news is good news:

$ dcopserver
$ dcop
$ kdcop
$
 

I tried the earlier items to resolve this by removing .DCOP and .ICE files in the respective folders but this didn't work in this latest case.  I decided then to test the applications how they behave when the dcop server is offline which could possibly give me more clues.   I shut down the dcopserver using dcopserver_shutdown which did as the name suggests, stopped the dcopserver and tried again using some of the above applications.  This time running dcop didn't produce DCOPClient::attachInternal. Attach failed Could not open network socket but still ended up returning ERROR: Couldn't attach to DCOP server!:

$ dcop
ERROR: Couldn't attach to DCOP server!
$

And again I reran kdcop but got different results this time around confirming I wasn't really starting dcop appropriately:

$ kdcop
kbuildsycoca running…
$

kdcop this time showed two applications listed in it's windows: kded, klauncher.  Looks like kdcop is running kbuildsycoca to start things up for me.  Another thing I noticed is that dcopserver only runs for about 15 seconds and dies after kdcop is launched which I didn't notice before.  Checking with ps axfo pid,ppid,user,cmd=|grep dcopserver following start of kdcop, I see this:

if it was not already running.  It should run automatically.  But this is only a temporary solution.  To get it to run automatically do this:

$ ps axfo pid,ppid,user,cmd=|grep dcopserver
 3348  2916 root          \_ grep dcopserver
 3336     1 root     dcopserver –nosid –suicide
$

Checking with dcop all sessions running are listed and appear to show up fine:

$ dcop –list-sessions –all-users
Active sessions for user /root :                   
  .DCOPserver_lhs.localhostservers__0              

Active sessions for user /root :
  .DCOPserver_lhs.localhostservers__0

$

So the above looks like the right way to start it and reading up we see that –suicide option causes the dcopserver to terminate after no connection to it have been made.  So it looks like KDE applications do support DCOP and appear to start it manually using kbuildsycoca when needed.  Great.  But konsole isn't which is where I needed it and I don't want the DCOP server to stop either.    I tried a number of kbuildsycoca options in combination with dcopserver to see if it will initialize a running server correctly, which it unfortunately didn't.  Running:

$ dcopserver_shutdown;dcopserver; DCOPSERVERID=$(dcopserver –serverid 2>&1); echo "|"$DCOPSERVERID"|"; kbuildsycoca –dcopserver $DCOPSERVERID

followed by running kdcop, still didn't populate anything and no applications such as kded and klauncher existed in the list. Of course running dcopserver –serverid produced:

$ dcopserver –serverid
local/lhs.localhostservers:/tmp/.ICE-unix/dcop3517-1227797617
$

I tried kbuildsycoca –help-all for clues to the problem and noticed a –config option suggesting perhaps kdcop is running kbuildsycoca with options.  However, when running kbuildsycoca by itself restarted the dcopserver and populated it just fine, so it wasn't really clear what is the difference here.  Was stuck at this point for a while until I used strace to try and capture what kbuildsycoca does to startup the dcopserver correctly:

$ strace kbuildsycoca 2>kbuildsycoca-strace.txt

Which produced a 1MB file with calls made by kbuildsycoca.  Looking through the file I see this (With interesting stuff marked in green):

/root/konsole/kbuildsycoca-strace.txt
.
.
.
open("/root/.DCOPserver_lhs.localhostservers__0", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
uname({sys="Linux", node="lhs.localhostservers", …}) = 0
open("/root/.DCOPserver_lhs.localhostservers__0", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
access("/usr/bin/kdeinit", F_OK)        = 0
access("/usr/bin/kdeinit", X_OK)        = 0
lstat64("/usr/bin/kdeinit", {st_mode=S_IFREG|0755, st_size=94308, …}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7fac748) = 9885
waitpid(9885, kbuildsycoca running…
[{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 9885
— SIGCHLD (Child exited) @ 0 (0) —
write(8, "\0", 1)                       = 1
sigreturn()                             = ? (mask now [])
uname({sys="Linux", node="lhs.localhostservers", …}) = 0
open("/root/.DCOPserver_lhs.localhostservers__0", O_RDONLY|O_LARGEFILE) = 13
fstat64(13, {st_mode=S_IFREG|0644, st_size=67, …}) = 0
fstat64(13, {st_mode=S_IFREG|0644, st_size=67, …}) = 0
fstat64(13, {st_mode=S_IFREG|0644, st_size=67, …}) = 0
fstat64(13, {st_mode=S_IFREG|0644, st_size=67, …}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d6e000
read(13, "local/lhs.localhostservers:/tmp/"…, 4096) = 67
close(13)
.
.
.

 

Looking at the calls we see that /usr/bin/kdeinit is ran by kbuildsycoca.  However, since we are running KDE 4.X, we are really running /usr/bin/kdeinit4 NOT /usr/bin/kdeinit and doing some digging on the matter, according to the earlier KDE Startup sequence and the current KDE startup sequence, we see that dcopserver is no longer part of the list of servers to start in KDE 4.  On another note it could mean my installation had KDE3 and KDE4 still on the system but do recall something in the upgrade process mentioning that KDE4 still relies on KDE3 code (Perhaps that's why it didn't remove it?)  In any case I ran /usr/bin/kdeinit to see if it made a difference:

$ /usr/bin/kdeinit
kbuildsycoca running…
$

This time the dcopserver was started without the –suicide flag so it would not exit per checks:

$ ps axfo pid,ppid,user,cmd=|grep dcopserver
 5042  2916 root          \_ grep dcopserver
 5026     1 root     dcopserver –nosid
$

Following above, dcop now produced the expected output:

$ dcop
kded
klauncher
$

Now how to make this permanent.  Checking the KDE 4 / X Windows startup sequence, we see that /usr/bin/startkde is the initial script where the dcopserver call and startup was initially made in earlier versions, so this file is a good candidate.  We see two lines in the /usr/bin/startkde script that are of interest:

$ vi /usr/bin/startkde
.
.
# kde3 kdeinit_shutdown 2>/dev/null
# kde3 dcopserver_shutdown –wait 2>/dev/null

.
.

echo 'Running /usr/bin/kdeinit to start dcopserver and accomodate for old applications which have not yet been updated to use DBUS….' 2>&1
nice -n 19 /usr/bin/kdeinit

echo 'startkde: Done.'  1>&2
 

Per above, comment out the lines in red and add the lines in green before the last statement which includes …Done… .  Restart KDE by either restarting your machine or typing init 1 then init 5 once you are at the shell prompt to restart the GUI.  Once you are back in, typing dcop should yield something similar to (and definitely not include any of the above errors):

$ dcop
kaffeine
kded
klauncher
$

Notice, kaffeine, another music player I've ran starts up and connected to the current instance of dcop now.  Though above removed a large source of errors since upgrading to KDE 4, not all applications that used to work with DCOP continue to work with DCOP after KDE 4 but this can provide some backwards compatability.  As mentioned above, one of these is konsole.

2 Responses to “Fedora & KDE: ERROR: Couldn’t attach to DCOP server!”

  1. [...] dí con un blog que contiene esta entrada. En ella se enumeran una serie de soluciones. A continuación paso a explicar cuál [...]

  2. Thanks for the information.

    I replaced kdeinit4 with kdeinit in startkde as my solution on Centos 6.6 and haven't seen a problem but I don't use too many programs. Do you know which programs will fail with my solution?

     

    Thanks

Leave a Reply

 


     
  Copyright © 2003 - 2013 Tom Kacperski (microdevsys.com). All rights reserved.

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License