This article contains instructions for collecting logs from various sync prcesses, be it Google, EAS, Dropbox or anything.
1. PREPARE FOR COLLECTING JOURNAL
To collect logs, follow these steps:
- Enable the developer mode on your device.
- Open an SSH terminal to your device (SSH Ubuntu, SSH Windows), and check that configuration file
Storage=persistentto ensure that journal is persistent over device reboots and that logs don't get truncated. If those values are different, or if those keys are commented out (prefixed by hash or semi-colon), edit the file as root. If needed, read more about the available text editors.
- Save it, and then reboot your device and open an SSH terminal to it again once it has booted.
2. BASIC SYNC LOGS
Here we prepare your device for collecting the actual sync logs. Note that rebooting the device will bring it back to its normal state. Hence the settings below are in effect till the next reboot only.
- Stop the sync daemon so that it can later be restarted with extra logging enabled, via (as a normal user, nemo)
systemctl --user stop msyncd killall msyncd # this may yield "no such process" - just ignore it.
- Start the sync daemon with extra debug logging enabled, via
MSYNCD_LOGGING_LEVEL=8 msyncd 2>&1 | cat > /home/nemo/msyncd.log
- Trigger a sync cycle by opening up "Settings > Accounts". Then long-press either the account you want to debug. Tap Sync in the pop up menu.
- Wait for 30 seconds or until the sync cycle has completed. The logs collected from the msyncd terminal were saved to the following file
Once done, consider reverting
/etc/systemd/journald.conf to its original values. Reboot the device in any case to escape the debugging mode.
3. MORE DETAILED LOGS ON CONTACT SYNC
The level of debugging enabled in step 2 of chapter 2 does not make the system print out too much data on contact sync. If there is a need to get deeper insight to the issues in contact sync then consider using the following setup
(make sure that you copy the whole long command):
devel-su -p QTCONTACTS_SQLITE_TRACE=1 MSYNCD_LOGGING_LEVEL=8 msyncd 2>&1 | cat > /home/nemo/msyncd.log
Hence follow the instructions of chapter 2 otherwise but replace step 2 with these commands.
4. DETAILED EAS LOGS
Various processes can be made more verbose by setting certain environment variables:
MSYNCD_LOGGING_LEVEL=8 # any Buteo sync plugin
Some processes can be made more verbose by editing certain configuration files and rebooting. The file below is for the configuration of Exchange ActiveSync plugin.
For example, to make the Exchange ActiveSync plugin fully verbose, first ensure that journald won't throttle logging output (see the notes on editing /etc/systemd/journald.conf in chapter 1 above) and then ensure that the
/home/nemo/.config/eas-sailfish.conf file contains the following:
On Sailfish OS version 3.0.2 and newer: [logging] Sailfish.eas=d Sailfish.easnetwork=d Sailfish.easwbxml=d Sailfish.logfile=/home/nemo/eas.log Earlier versions: [logging] Sailfish.eas.debug=dwc Sailfish.eas.error=dwc Sailfish.eas.warning=dwc Sailfish.easnetwork=dwc Sailfish.easwbxml=dwc Sailfish.logfile=/home/nemo/eas.log
5. COLLECT THE JOURNAL LOG
Now that you have done the sync debugging, it is the time to collect the generic log, i.e. the journal:
Saving logs is always useful - here it goes to a file:
devel-su journalctl -a -b > /home/nemo/sync-journal.txt
6. SENDING LOGS
You should now have the foillowing log files:
These files can be sent to Jolla customer service or to chris dot adams at jolla dot com or you can create a bug report about the issue on the Mer Bug Tracker. Please ensure that you redact any personal information (usernames, passwords, phone numbers, addresses, or other sensitive personal information) before sending the logs or posting them to the public Mer Bug Tracker.
The log files probably contain personal information from you. We will not share them in public but simply look for technical issues in them by a chief engineer in Jolla R&D. If you are in doubt, glance through the files or do not send them at all.