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

[Thiago Macieira]

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.

> 2. Is the behavior, Christian reported about the delay on closing
> sockets on windows and it difference to unix somewhere documented ?

No idea. It might be a difference between TCP and Unix sockets. I.e., the 
operating system tries to send unsent bytes after the socket closes -- 
including when the app terminates or crashes.

This should not happen since there should be no unsent bytes.

But in all implementations, sockets close when the application that had them 
open exits. It does not make any sense at all to keep a socket open past the 
application's lifetime.

So, one of two conditions:
1) the socket did close, but dbus-daemon.exe did not notice it. It's probably 
a Windows porting bug or some kind of stupid Winsock behaviour. I can't see 
anything special about handling remote closes on Qt's Windows code.

2) the socket somehow did not close, but this doesn't make sense if the 
application terminated.

> 3. Are there any possible option in setting socket options ?  The only
> option I found in setsockopt
> http://msdn2.microsoft.com/en-us/library/ms740476(VS.85).aspx  looks
> like to be
> SO_DONTLINGER   BOOL    Does not block close waiting for unsent data to be
> sent. Setting this option is equivalent to setting SO_LINGER with
> *l_onoff* set to zero.

I don't know. If we set to not linger, then we may be throwing away some D-Bus 
messages that should've been sent.

> but I cannot say if the current problem is caused by unset data.  If
> there is no socket option it will be required to fix this issue in KDE's
> code. I cannot see any way how to fix this in dbus.

It CANNOT be properly fixed in KDE code.

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)?

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080219/5c9cc33f/attachment.sig>