Patrick Ohly wrote:
On Fr, 2010-02-19 at 11:49 +0000, Patrick Ohly wrote:
I think we are all learning about this. Let's see what the reason was in
this particular case.
A segfault. SyncEvolution core prepares for that by recording a bad
result for the session, which has to be overwritten later on:
synchronization process died prematurely
/** command failed / fatal DB error */
STATUS_FATAL = 500
That was introduced before we started to distinguish between local and
remote errors. The error code should have been 500 + LOCAL_STATUS_CODE
to mark it as a local problem.
Ok, this would have been shown on the UI as: "There is a problem with
the local database. Syncing again or rebooting may help." The suggestion
is there because this is what we see if EDS goes bonkers -- obviously
not very useful in this case.
In this particular case, should we introduce a special status for "died
prematurely"? Like a new SyncEvolution specific STATUS_DIED_PREMATURELY
= 22002?
This would be what syncevolution writes in status.ini before starting to
work (so that if it does die, the status is correct)? Sounds good to me.
There is something in syerror.h:
/** base code for linux signals (SIGXXX). SIGXXX enum value will be
added to LOCERR_SIGNAL */
LOCERR_SIGNAL = 20500
But we cannot use that because we should better not try to overwrite
status.ini after the process went bad because of a signal.
I can't imagine that I'd want more details in the UI than "sync service
died prematurely": at that point one needs to look at logs and such
anyway regardless of the signal, right?
Jussi
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
