Comment 8 for bug 738555

Revision history for this message
Markus Korn (thekorn) wrote :

I was investigating on this bug a bit further. All Tracebacks are looking like

Traceback (most recent call last):
  File "/usr/bin/zeitgeist-daemon", line 180, in <module>
    handle_exit()
  File "/usr/bin/zeitgeist-daemon", line 126, in handle_exit
    interface.Quit()
  File "/usr/share/zeitgeist/_zeitgeist/engine/remote.py", line 349, in Quit
    self._engine.close()
  File "/usr/share/zeitgeist/_zeitgeist/engine/main.py", line 133, in close
    self.extensions.unload()
  File "/usr/share/zeitgeist/_zeitgeist/engine/extension.py", line 287, in unload
    self.unload(ext)
  File "/usr/share/zeitgeist/_zeitgeist/engine/extension.py", line 292, in unload
    obj.unload()
  File "/usr/share/zeitgeist/_zeitgeist/engine/extensions/datasource_registry.py", line 115, in unload
    self._write_to_disk()
  File "/usr/share/zeitgeist/_zeitgeist/engine/extensions/datasource_registry.py", line 99, in _write_to_disk
    with open(DATA_FILE, "w") as data_file:
IOError: [Errno 2] No such file or directory: '$XDG_HOME_DATA/zeitgeist/datasources.pickle'

This is telling us a few things:

 1.) the crash happens when handle_exit() is called, this function is called when the daemon recieves a SIGHUB or SIGTERM signal, means if the systems wants zg to shut down. (apport will try to report this crash on the next session start, which makes people think this crash happen *while booting*)

 2.) If you try to write to a certain location in python, and the parent directory of this location does not exist at this point, an IOError with "[Errno 2] No such file or directory: [...]" is raised. This indicates that $XDG_HOME_DATA or $XDG_HOME_DATA/zeitgeist does not exist for the bugreporters when the systems wants zg to shut-down.

 3.) All bugreporters are having their $HOME (or parts of it) encrypted ("EcryptfsInUse: Yes"). This *could* be the reason for this bug, *maybe* the encrypted dir (and thus $XDG_HOME_DATA) get un-mounted before the system wants zg to stop.

So this leads to a simple question: How do we want zg to behave if it is impossible to write the data to its DATA_PATH (which is in most cases $XDG_DATA_HOME/zeitgeist)? We are talking about these files atm:

 1.) activity.sqlite
 2.) datasources.pickle
 3.) blacklist.(pickle|json)
 [4.) extension specific files, like the fts index]

IMHO three of them are easy to handle. We should not care about 4.) at the first place, it's up to the (3rd party) extensions to do the right thing, but we have to tell extensions authors what we think is the best they could do. If the datasource registry fails to write its config file on shutdown it does not really matter, as its data is written on every change to this file anyway. We should just ignore this error on shutdown and log a warning. If config can not be written when AddTemplate or RemoveTemplate dbus method gets called we should log the error, and return the error over dbus, but not let the daemon crash. The requested config changes should not have any effect. Some goes for blacklists.
I'm not sure how to handle the activity log here. Data gets written to this file (sqlite3.connection.commit()) as a result of dbus calls, for which we should log this error, revert in memory changes and send an error over dbus. But we are also writing to this file on start/shutdown of the daemon, which is not an explicit user action. We should log the write error in this cases and do the best to tell our users which kind of actions were not logged properly.
As a future step we could also try to shutdown the daemon before the DATA_PATH becomes unavaiable.

@Mikkel, Siegfried, Seif, et all. Any comments on this topic?