Hello, currently, when DBus connection goes down trackerd exits with status set to 1. The culprit is dbus-daemon that runs as a per-user session process. When it goes down trackerd follows. A DBus aware process can avoid this exit with: dbus_connection_set_exit_on_disconnect (connection, FALSE); (It is required because dbus_bus_get() always set 'exit_on_disconnect' to TRUE otherwise it would stay to FALSE) Now trackerd doesn't crash anymore when it looses its connection to DBus... but it won't be able to reconnect to DBus anymore, so trackerd has to be shut down. In fact, it is also useful to make trackerd exits on a DBus disconnection because GNOME, KDE, XFCE, whatever, runs a dbus daemon that will exit at end of session. Therefore treackerd is currently crashing at end of session (look at trackerd's logs). It is possible to catch the 'disconnected' signal from DBus and to make trackerd exiting after a DBus disconnection. I propose a patch that implement this idea. But this patch is not very clean... I added a DBUS_ACTION named DBUS_ACTION_DBUS_DISCONNECTED. I do not really like it since a disconnection is not a DBUS action from a user... I also wonder if we should extend how DBus treat DBus signals. If I remember correctly, it is possible to use DBus to catch a signal (from I-do-not-remember-what) to know whether a battery is going empty. In this case, trackerd could stop to extract data but could continue to index files and to answer to user requests. You also see that I created a sort of new signal, the 'DBus connection lost' for do_cleanup() in trackerd.c. :-) My patch is mainly to show the DBus/end of session problem and to think how to do it cleanly. Laurent.
Attachment:
dbus-connection-lost-handling.diff
Description: Text Data