Thanks everyone for the help on this, but I'm not sure I follow what has been suggested. I have been playing around tonight with connecting the signals when I start the listener. For a simple test listener, I tried: dbus_loop = DBusGMainLoop() bus=dbus.SessionBus(mainloop=dbus_loop) tbird_object = bus.get_object("org.mozilla.thunderbird.DBus" , '/org/mozilla/thunderbird/DBus') interface = dbus.Interface (tbird_object, "org.mozilla.thunderbird.DBus") interface.connect_to_signal("NewMail", new_mail_callback) But I get the error: dbus.DBusException: org.freedesktop.DBus.Error.ServiceUnknown : The name org.mozilla.thunderbird.DBus was not provided by any .service files This problem is what led me down the path of connecting to the signals after registration. The other problem was that it was starting those that were not yet started (for example, Rhythmbox would start if I tried to connect). I noticed the line "You shouldn't use proxy objects just to listen to signals, since they might activate the relevant service when created, but if you already have a proxy object in order to call methods, it's often convenient to use it to add signal matches too." from the dbus-python tutorial, but it wasn't clear to me how to avoid this (by not using proxy objects). Also, could you clarify what you mean by "  2) request the current state that would be notified about by the signal" What kind of request is this? I'm hoping I can figure out how to implement what has been suggested, so it may not be a concern - I would just like to understand what you mean by this. Thanks again, Jim <div>On 8/1/07, Havoc Pennington <<a href="mailto:hp@redhat.com">hp@redhat.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Thiago Macieira wrote: > Jim Kytola wrote: >> For full disclosure, I have another script that listens for >> NameOwnerChanged and when it finds the org.mozilla.thunderbird.DBus >> change, connects a callback function to the NewMail signal - so by >> successful run, I mean the callback function gets fired. It's certainly >> possible that my problem is on that side, but it does seem strange that >> I'm seeing the NewMail signal before the GetNameOwner method call in >> the bad run. > > This is your problem: you're waiting for the application to register. > > Don't. > > Connect the signal as soon as the listener starts. When the application > starts, register and emits the signal, your listener will have already > set everything up. In fact, it won't even need to listen for the > NameOwnerChanged signal. > To add to this a bit, whenever you connect to a signal *after* the emitter exists you need to use this pattern:   1) connect to signal   2) request the current state that would be notified about by the signal (in that order) Any API with signals must have a way to do 2) or it's broken, because an app can't connect race-free. But Thiago is certainly right that you need not wait for the bus name to exist before you match for signals on it. Havoc _______________________________________________ dbus mailing list <a href="mailto:dbus@lists.freedesktop.org">dbus@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/dbus">http://lists.freedesktop.org/mailman/listinfo/dbus</a> </blockquote></div>