To overcome this, I tried with sending two method_call at a single go, that didn't helped too. In some cases both the signals/method_call are lost, and in some if I am lucky I get one of them. In most cases both the "duplicate" signals/method_call were lost. Is there a patch for this bug. If not can you direct me to the part of the code which needs to be looked in-to ? I don't have the luxury of having --print-reply because the dbus-send part has to go into DHCP server which is a single threaded application. However for de-bugging I can have them in my current shell-script. <div class="gmail_quote">On Thu, May 14, 2009 at 10:49 PM, Colin Walters <<a href="mailto:walters@verbum.org">walters@verbum.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;"> <div class="im">On Thu, May 14, 2009 at 1:07 PM, Abhijeet Kumar Sinha <<a href="mailto:abhijeet.aks@gmail.com">abhijeet.aks@gmail.com</a>> wrote: > > dbus_connection_read_write(conn,0); > msg = dbus_connection_pop_message(conn); > if ( NULL == msg ){ > usleep(1000); > continue; > } > I re-wrote the code using glib, to use the glib mainloop. </div>I wanted to reply to your earlier message to this effect - I'm not sure that loop is correct, though it needs analysis. Basically, using DBus not with a mainloop is tricky and not as well tested. <div class="im"> > random_dbus_signal.sh -- is the client side script which sleeps for random > seconds and then wake up and calls a method of the server -- uses dbus-send > --system --type=method_call </div>Unfortunately, there is definitely a DBus bug here. You need to use --print-reply. See discussion here: <a href="http://lists.freedesktop.org/archives/dbus/2009-March/011054.html" target="_blank">http://lists.freedesktop.org/archives/dbus/2009-March/011054.html</a> </blockquote></div> -- Regards, Abhijeet