On Tue, 2009-10-13 at 15:38 +0100, Patrick Ohly wrote:
dbus-monitor buffers its output and doesn't flush it when
means that output is lost. Stupid dbus-monitor. No solution :-/
dbus-monitor has broken SIGINT handling and no handling of SIGTERM.
Because of its brokeness, distros patch this out of their dbus-monitor
binaries. Here's a patch which fixes dbus-monitor. I'm not sure yet how
useful catching a D-Bus log with dbus-monitor will be - we'll see...
Author: Patrick Ohly <patrick.ohly(a)gmx.de>
Date: Wed Oct 14 14:20:00 2009 +0200
dbus-monitor: fix for CTRL-C/SIGINT and SIGTERM
CTRL-C/SIGINT had no effect because dbus_connection_read_write_dispatch()
continues with poll() after an interrupted system call. This
caused Debian and Ubuntu to remove the signal handling code since 1.1.1-1:
This patch solves the problem using brute force: a timeout of 500ms
ensures that dbus_connection_read_write_dispatch() is left often
enough to react to signals in a more or less timely manner. Nicer
solutions are of course possible (custom main loop), but also more intrusive.
In addition, this patch also catches SIGTERM. This is the default
signal used by kill and Python's subprocess.terminate() and thus worth
diff --git a/tools/dbus-monitor.c b/tools/dbus-monitor.c
index 873108b..03600b0 100644
@@ -339,9 +339,15 @@ main (int argc, char *argv)
- /* we handle SIGINT so exit() is reached and flushes stdout */
+ /* we handle SIGINT and SIGTERM so exit() is reached and flushes stdout */
signal (SIGINT, sigint_handler);
- while (dbus_connection_read_write_dispatch(connection, -1)
+ signal (SIGTERM, sigint_handler);
+ * The signal alone won't get us out of dbus_connection_read_write_dispatch(),
+ * it seems to simply call poll() again. Check for termination every
+ * 500ms.
+ while (dbus_connection_read_write_dispatch(connection, 500)
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.