Working on the Calendar feature¶
The Calendar feature is provided by several components:
The Calendar App, providing the user interface
Evolution Data Server (often shortened as “EDS”), which is the backend where your calendars are stored
sync-monitor, the service responsible for managing the synchronisation with remote calendars
SyncEvolution, the service responsible for performing the synchronisation to a WebDAV/CalDAV remote calendar
Debugging¶
The most convenient way to run commands on the device and collect logs is by opening a remote shell. This can be done by using Shell access via ADB or Shell access via SSH. In the following sections, it’s assumed that you’ve got access to a terminal console to the device.
Scheduling and account issues¶
If you are not sure whether the calendar is being synchronised, or whether the operation is successful, sync-monitor
is the component that needs to be examined. This service should always be running in the background, and its logs can be found in ~/.cache/upstart/sync-monitor.log
. In order to see them printed in real-time as you operate on the device, you can run this command:
tail -f .cache/upstart/sync-monitor.log
These logs should be enough to give you an idea on whether your calendar accounts are recognised, and whether a synchronisation is scheduled, happening, and completing successfully.
Calendar data synchronisation issues¶
Follow these steps one you are confident that a synchronisation of your account is at least attempted, and want to investigate a synchronisation failure or issues with missing or duplicate items. On the device, it’s possible to run syncevolution
in debug mode. To do so, kill any existing processes:
pkill sync-evo
Then, start the syncevolution
process with the proper environment variable:
SYNCEVOLUTION_DEBUG=1 /usr/lib/arm-linux-gnueabihf/syncevolution/syncevo-dbus-server
At this point, open the Calendar App (if it was not open already) and manually trigger a synchronisation (note that the Synchronisation action is only available if your device is connected to the internet): all the logs will appear in the terminal.
In some cases, the output from syncevolution
might not be enough: for example, the raw HTTP data is usually not printed. Should you need to see that as well, then you’ll have to modify a configuration file as well. syncevolution
’s configuration files are located under ~/.config/syncevolution/
, in a subdirectory whose name takes the form <provider-name>-<account-id>
. There might be stale directories as well, referring to old accounts which have been since deleted. To find out what accounts are still valid, you can invoke the account-console
tool like this:
account-console list
This will print the list of the current valid accounts. Once you’ve figured out what is the account you are interested in, open the file ~/.config/syncevolution/<account>/peers/target-config/config.ini
and set the loglevel
variable to a higher value (11
seems enough to print all the HTTP traffic):
# level of detail for log messages:
# - 0 (or unset) = INFO messages without log file, DEBUG with log file
# - 1 = only ERROR messages
# - 2 = also INFO messages
# - 3 = also DEBUG messages
# > 3 = increasing amounts of debug messages for developers
loglevel = 11
Note that in order for these changes to take effect, you’ll need to restart the syncevolution
process again, as explained above.