KMaiL: Can't setup D-Bus service. Probably already running.

Ralf Habacker ralf.habacker at
Tue Feb 19 22:16:54 GMT 2008

Thiago Macieira schrieb:
> On Tuesday 19 February 2008 15:56:34 Ralf Habacker wrote:
>> ... but this does not help to find a solution for the reported issue,
>> which requires to work together to find a way out or this problem will
>> still remain.
>> 1. Which condition enables dbus to detect that a connection is close and
>> where in  the dbus code is this located ? This is required to generate
>> testcases and/or find the right place for additional debug messages in
>> dbus code.
> It detects that the connection closed in its select() main loop. When one 
> client goes away, the (Unix) socket closes automatically and immediately. The 
> dbus-daemon then gets a read notification. When it tries to read, it gets 0 
> bytes, indicating EOF. Then it proceeds to release all resources associated 
> with that client.
> That's on Unix. I have no idea how you guys implemented the mainloop on 
> Windows. I know the Qt event loop uses a WSAAsyncSelect, but that's not 
> necessary for dbus-daemon (since it has no GUI). It can use a normal, 
> Unix-style select() with timeout.
it does uses select() too, there is a  platform indendepent wrapper 
called _dbus_poll()
> <snip>
> What happens to non-KDE Qt applications? How about other D-Bus applications 
> running with libdbus-1? Or without it (like the Java or NDesk/C# bindings)?
I have append a qt based testcase using qdbus to analys the 
registerService()/unregisterService() functions

first test scenario
cmd> start registertest 30  => run registerService and wait 30 sec
cmd> registertest 3 => run registerService and wait 3 sec
-> second process cannot register name, which is the expected behavior

second test scenario
cmd> registertest 3  nounregister && registertest 3  nounregister => run 
registerService without unregisterService() for 3 sec, then run another 
registerService without unregisterService() for 3 sec
this simulates the situation, that unregisterService() wasn't called on 
application exit.
-> the second process can register the name without any problems, which 
means windbus using QDBus works as expected.

How to proceed now ?


-------------- next part --------------
A non-text attachment was scrubbed...
Type: application/x-zip-compressed
Size: 14821 bytes
Desc: not available
URL: <>

More information about the kde-core-devel mailing list