I found an easier way to replicate the error.
1) Open Terminal (terminal1) and run "zeitgeist-daemon --replace"
2) Open another terminal (terminal2) and do "cd ~/.local/share/" then "mv
zeitgeist zeitgeist-backup"
3) In terminal1 then do "Ctrl+c" to quit Zeitgeist
(remember to move the zeitgeist-backup again to zeitgeist else you will lose
your data)
Cheers
Seif
On Thu, Apr 21, 2011 at 5:24 PM, Seif Lotfy <email address hidden> wrote:
> So this looks to me like a problem not only Zeitgeist is facing but
> anything that is running and wants to write to disk upon session end.
>
>
> On Thu, Apr 21, 2011 at 5:07 PM, Seif Lotfy <email address hidden>wrote:
>
>> So as Markus said, the crash report comes from the session before.
>> This implies that the home directory is unmounted or encrypted again
>> before zeitgeist can write something to it when it receives a SIGHUB or
>> SIGTERM signal.
>> The solution to this either to not allow the datasource register y to
>> write to disk upon the occurrence of these signals. This means there could
>> be a dataloss in the datasource. I will need to further investigate this
I found an easier way to replicate the error.
1) Open Terminal (terminal1) and run "zeitgeist-daemon --replace"
2) Open another terminal (terminal2) and do "cd ~/.local/share/" then "mv
zeitgeist zeitgeist-backup"
3) In terminal1 then do "Ctrl+c" to quit Zeitgeist
(remember to move the zeitgeist-backup again to zeitgeist else you will lose
your data)
Cheers
Seif
On Thu, Apr 21, 2011 at 5:24 PM, Seif Lotfy <email address hidden> wrote:
> So this looks to me like a problem not only Zeitgeist is facing but
> anything that is running and wants to write to disk upon session end.
>
>
> On Thu, Apr 21, 2011 at 5:07 PM, Seif Lotfy <email address hidden>wrote:
>
>> So as Markus said, the crash report comes from the session before.
>> This implies that the home directory is unmounted or encrypted again
>> before zeitgeist can write something to it when it receives a SIGHUB or
>> SIGTERM signal.
>> The solution to this either to not allow the datasource register y to
>> write to disk upon the occurrence of these signals. This means there could
>> be a dataloss in the datasource. I will need to further investigate this