So indeed this turned out to be true. The daemon is getting something bad (an invalid message) from my process B. Turning debug verbose on the daemon shows this... 289: handling read watch 0xcfe30 flags = 1 289: do_reading: fd = 6 289: check_read_watch: fd = 6 289:   setting read watch enabled = 1 289:   UNLOCK: protected_change_watch 289:   LOCK: protected_change_watch 289:  read 844 bytes 289: Initial peek at header says we don't have a whole message yet, or data broken with invalid code 13 289: Corrupted message stream, disconnecting 289: _dbus_transport_disconnect start 289: socket_disconnect Since my process B just handles the filter message and does not send anything, i can only think of two things... 1. Some thread in my process has a socket descriptor wrong, hence is dumping things by mistake into the dbus socket fd. 2. There is some bug in dbus code, that is sending this invalid message. To rule out 2. i have a question that may be someone can help with. If we assume process B just has code to set an addmatch and recv a signal and If the daemon passes a signal message to B, B does not have to ack or send anything back correct?. It should just get the message and handle it and go its way. When things work correctly i see this is indeed the case, the daemon sends something and does not hear back from Process B. The whole thing seems to be very time sensitive w.r.t process B, if dbus_verbose is turned on B this does not happen. Thanks. -K <div>On 4/11/07, Thiago Macieira <<a href="mailto:thiago@kde.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">thiago@kde.org</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Krishna R wrote: >Further probing lead to disconnect signal being the cause of > do_io_error() in dbus-transport-socket.c, it was called because > do_reading() which reads from the socket and gets bytes_read = 0. That > means the socket was closed on the other end? Yes. >The question i have is why is the dbus-daemon closing the socket? Or is > it? It is and it does so because it received an invalid message. If you strace the daemon or if you run it in debug mode, it should say why it did that. >dbus-daemon, A and B are started one after another at boot in the >foreground. Is there some problem where the session bus is not fully >initialized? That may not be because atleast one signal from A reaches > B. I don't think so. -- Thiago Macieira - thiago (AT) <a href="http://macieira.info" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> macieira.info</a> - thiago (AT) <a href="http://kde.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">kde.org</a>   PGP/GPG: 0x6EF45358; fingerprint:   E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 </blockquote> </div> -- P.R.Krishna