Created attachment 472155 [details]
Fix

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Created attachment 472280 [details]
Test case

Compile:

  gcc -o dbus-bug dbus-bug.c `pkg-config dbus-1 --cflags` `pkg-config dbus-1 --libs` -D_GNU_SOURCE

usage:

  ./dbus-bug [w]

  (if argv[1] is present, it enables a poll() workaround which is similar
   to the patch provided)

Expected behavior:

   Program should exit after dbus-daemon is killed.

Behavior with unpatched dbus-1.2.24-3.el6:

   Program never exits.

Behavior with patched dbus-1.2.24-3.el6:

   Program exits after the dbus-daemon has been killed.

Behavior in both cases when workaround is enabled:

   Program exits after the dbus-daemon has been killed.

We can use the workaround as provided in this test case if required, however, since we'll have to duplicate it several times (once in each daemon), it makes more sense to fix the dbus library.

BTW, if you comment out the following line in dbus-bug.c:

    dbus_connection_set_exit_on_disconnect(dbc, FALSE);

... the behavior of the program does not change in any test case.

dbus_connection_flush() detects dbus-daemon's death in a timely manner as well.

http://dbus.freedesktop.org/doc/api/html/group__DBusConnection.html#ga580d8766c23fe5f49418bc7d87b67dc6

^^ Also can be used in a thread to detect connection death.

(In reply to comment #6)
> dbus_connection_flush() detects dbus-daemon's death in a timely manner as well.

If you're not using a mainloop to talk to dbus (as "dbus-bug" isn't), then I think the right thing to do is call dbus_connection_flush() after you're done with any dbus_connection_send()s.  This would be line 148 of dbus-bug.c.

The docs for dbus_connection_send() do say that a flush() is unnecessary *if* you're using a mainloop, but they don't make it clear that it really *is* necessary if you're not, otherwise the state is sort of undefined.

I'm not entirely sure about your patch; it smells right but I'd need to truly understand what it could possibly change.

Can you confirm if you add the dbus_connection_flush() that the test case works as expected?

dbus_connection_flush() works, as noted in comment #6.

We went the other route for now, adding a thread which calls dbus_connection_read_write() in a loop, which also picks up if the dbus-daemon dies.

I assume both at some level do some sort of non-POLLHUP error checking if the dbus-daemon died (ex: "select() said there was data ready to read, but read returned 0 -> oops, connection died").  I didn't investigate that much.

So, this might be a case of WONTFIX - but in talking with others, not checking POLLHUP seemed to be a bug, so I left this open.

dbus_connection_send() sends a message immediately if it can, and only queues it if it can't send it immediately (by calling poll()).  When it goes to try to send, it calls poll().

If we check POLLHUP, we can immediately detect the connection is dead instead of queueing, waiting for the other thread to wake up do its error detection (which I still need to look at) and handling it later.