On Mon, 2018-02-12 at 10:35 +0100, Alain Knaff wrote:
When trying to use synccalendar, I occasionally get the following:
[INFO @aev] operation temporarily (?) failed, going to retry in 5.0s
before giving up in 298.7s: REPORT 'check for items': bad HTTP
status: <status 1.1, code 503, class 5, Service Unavailable>
And then repeats the message with ever growing delays.
503 indicates a temporary error, so the WebDAV layer is correctly
retrying it for a while. If that problem persists for certain
operations, then the server operator and/or developer needs to
Apparently, sync-evolution or the server doesn't like a certain
entry, and rather than move on to the next, just gets stuck on it.
Primarily this is the server. It could of course also be caused by bad
data being sent by SyncEvolution, but then the server should outright
reject it instead of reporting a temporary error.
Sometimes killing syncevolution, and then starting it again fixes
issue, and sometimes not. Btw, to kill syncevolution, just using
doesn't do the job, you've actually got to use the kill command from
another terminal session, or use Ctrl-Z and then kill.
You should get a message that you need to use Ctrl-C twice to abort
immediately. Otherwise it tries to suspend the sync, which is less
intrusive and may allow resuming it the next time.
But I just tried that and noticed that there is no such message. I'm
testing a fix. Ctrl-C twice however should work.
May I suggest three small changes to make this issue much less
1. When such a thing occurs, actually say *which* calendar entry
this. For most practical cases date, time and title should be enough
uniquely identify the entry and allow the user to "manually" transfer
(i.e. manually delete it on phone, manually change/create it on
and sync it back), or even to allow him to understand what is
This isn't as easy to implement as it seems. The layer which runs into
the temporary error has no idea what item it is dealing with, and in
some cases the "offending" calendar entry might not even be in the
operation (for example, a PUT which removes some item from a larger
Once the operation times out, the upper layers should print a proper
ERROR message about the failed items. As the error in your case isn't
really "temporary" and retrying the request doesn't make it go away,
you might want to reduce the RetryDuration in your target configuration
(the WebDAV side).
2. The message just echoes the HTTP Status line, and not the rest of
contents of the server's error page. Maybe the server (MS Exchange
davmail) does indeed explain what's the issue with that calendar
Bad status? Bad Reminder options? etc.? Impossible to know easily,
nowadays most server use HTTPs and so even tcpdump wouldn't be any
How should SyncEvolution render the error response? Quite often it is
HTML. There's also the risk of spewing a lot of text to the console.
The INFO message is intentionally a single line.
If someone wants to know more, they should run with a high log level
(like 10) and look at the HTML log file for a failed sync to learn more
about the individual HTTP requests.
3. Rather than just retrying forever, syncevolution should skip over
entry, move on to the next, and repeat in the final summary message
such-and-such entry was skipped (and identify the entry as described
It shouldn't retry forever. The default is 5 minutes. Remember that
this is for the case where the server really is loaded. Giving up a
sync too soon would just make the situation worse because the next sync
then might have to be done in slow mode, so IMHO it makes sense to try
for a while.
Other question: I run syncevolution on a BQ Aquaris E5 phone with
Touch. Ubuntu no longer supports touch, however, and apt-get upgrade
stopped working for a while. So I'm stuck at version
However, UBports has taken up this task, and I suppose they've got a
repository somewhere from which to get updates from them.
there site is silent on that issue, and only describes how to
ubports from scratch on a new device, and not how to upgrade an
Ubuntu touch device. Do you by chance know what to enter into
/etc/apt/sources.list to get updates from UBports rather than from
Sorry, I'm not familiar with Ubuntu phones (never had one).
Third question: due to this whole dropped support issue, I'm in
market for a new phone, and it will either be stock Android or
OS (due to current lack of other Linux alternatives :-( ). Does
syncevolution work on these two OS'es?
No, but there are other CalDAV/CardDAV clients, or you can sync the
phone directly with Exchange.
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.