Comment 69 for bug 1235649

FWICS D-Bus is behaving as designed: since the client has not called dbus_connection_set_wakeup_main_function(), and since D-Bus messaging is reliable, all libdbus is able to do when a signal is sent to a connection is cache any messages the client has not yet processed in the hope that at some future point it might consume them.

The key part of the D-Bus code that explains this is dbus_connection_send_preallocated_unlocked_no_update():

------------------------------

  /* Now we need to run an iteration to hopefully just write the messages
   * out immediately, and otherwise get them queued up
   */
  _dbus_connection_do_iteration_unlocked (connection,
                                          NULL,
                                          DBUS_ITERATION_DO_WRITING,
                                          -1);

  /* If stuff is still queued up, be sure we wake up the main loop */
  if (connection->n_outgoing > 0)
    _dbus_connection_wakeup_mainloop (connection);

------------------------------

As shown, the messages (signals in the case of Upstart) are added to the client connection queue, but since the client called
dbus_connection_open() rather than nih_dbus_connect(), no mainloop handler is registered to allow the client to deal with the signals sent to it.

From the upstart perspective, a fix is to call dbus_connection_has_messages_to_send() and ignore that connection if the
client still has unprocessed messages (patch attached).

From the D-Bus perspective, it would be useful to introduce a new public API:

dbus_bool_t
dbus_connection_has_wakeup_main_function (DBusConnection *connection);

This would allow Upstart and other D-Bus server applications to detect erroneous client connections.