Re: [SyncEvolution] writing unit tests for our new D-Bus API

On Tue, 2009-10-13 at 15:38 +0100, Patrick Ohly wrote: 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... commit f6719df9e3a545acf8600970190d3bd89cfd390a Author: Patrick Ohly <patrick.ohly(a)gmx.de&gt; 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: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414139 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 handling. diff --git a/tools/dbus-monitor.c b/tools/dbus-monitor.c index 873108b..03600b0 100644 --- a/tools/dbus-monitor.c +++ b/tools/dbus-monitor.c @@ -339,9 +339,15 @@ main (int argc, char *argv[]) exit (1); } - /* 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) && !sigint_received) ; exit (0); -- 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.