At the time of this writing (circa version 3.8), Evolution and Evolution-Data-Server have no centralized mechanism for generating debugging output. Typically each backend module -- be it a mail backend, calendar backend, or address book backend -- uses its own environment variable to control its own debugging output. This section documents those environment variables.
Since environment variables for debugging are typically set as part of the shell command that starts a process (e.g. CAMEL_DEBUG=imapx:io evolution), it's important to know which processes run which backends.
Mail backends run directly in the evolution application.
Calendar backends run in the evolution-calendar-factory daemon.
Address book backends run in the evolution-addressbook-factory daemon.
Mail backends run in the evolution application as extensions of the Camel library. The Camel library uses a single environment variable -- CAMEL_DEBUG -- to control debugging output. The general syntax of the environment variable is as follows:
CAMEL_DEBUG = module [":" subsystem] ("," module [":" subsystem])*
Camel's "IMAPX" backend makes extensive use of the "subsystem" feature of Camel's debugging system. Available subsystem options are listed below and are shown the way they would typically be invoked.
CAMEL_DEBUG=imapx:io evolution >& logfile
The imapx:io option follows the raw IMAP protocol exchanges with the IMAP server, and is generally the most useful for debugging communication or standard-compliance issues.
Note: The remaining subsystem options are less useful than imapx:io, but are listed here for completeness.
CAMEL_DEBUG=imapx:command evolution >& logfile
The imapx:command option follows the assembling and pipelining of outgoing IMAP commands, as well as acknowledegment of untagged IMAP responses.
CAMEL_DEBUG=imapx:token evolution >& logfile
The imapx:token option follows the parsing of individual string tokens read from the network stream, and is generally only useful for debugging issues with the IMAP parser.
CAMEL_DEBUG=imapx:parse evolution >& logfile
The imapx:parse option is a higher level parsing option which indicates the expected grammar of subsequent string tokens, as defined in the IMAP RFC documents.
CAMEL_DEBUG=imapx:debug,imapx:extra evolution >& logfile
The imapx:debug and imapx:extra options seem to be for miscellaneous and narrative debugging messages. It's not clear what the distinction was meant to be for these two options.
If a subsystem is not specified, as in CAMEL_DEBUG=imapx, then all subsystem options for imapx are enabled.
Debugging output for Camel's POP3 backend is enabled as follows:
CAMEL_DEBUG=pop3 evolution >& logfile
This follows the raw POP3 protocol exchanges with the POP3 server, as well as miscellaneous backend processing.
Debugging output for Camel's NNTP backend is enabled as follows:
CAMEL_DEBUG=nntp evolution >& logfile
This follows the raw NNTP protocol exchanges with the NNTP server, as well as miscellaneous backend processing.
Prior to E-D-S 3.10, Camel's SMTP backend defined no debug symbol of its own and had to be enabled through the special all value.
CAMEL_DEBUG=all evolution >& logfile # 3.8 or prior only
As of E-D-S 3.10, the SMTP backend defines its own debugging symbol:
CAMEL_DEBUG=smtp evolution >& logfile # 3.10 or later only
This follows the raw SMTP protocol exchanges with the SMTP server.
Synchronization for offline
To debug synchronization for offline, there can be used:
CAMEL_DEBUG=downsync evolution >& logfile
which is available since 3.28.5/3.30.0 and it logs what is done when the synchronization for offline is run, either manually or automatically.
Calendar backends run in the evolution-calendar-factory process. Each calendar backend defines its own environment variable(s) to enable debugging output, usually as a simple toggle in the form of FOO_DEBUG=1.
Debugging output for the CalDAV calendar backend is enabled as follows:
CALDAV_DEBUG=1 evolution-calendar-factory -w >& logfile
Below is the list of the available options. Multiple options can be specified as a comma-separated list.
The message* options enable libsoup's logging facilities:
CALDAV_DEBUG=message:body sets the log level to SOUP_LOGGER_LOG_BODY.
CALDAV_DEBUG=message:header sets the log level to SOUP_LOGGER_LOG_HEADERS.
CALDAV_DEBUG=message sets the log level to SOUP_LOGGER_LOG_MINIMAL.
The items and attachments enable additional debug output directly from the CalDAV backend.
The all or 1 options enable message:body (the most verbose of the three message* options), as well as items and attachments options.
Debugging output for the WebCal calendar backend is enabled as follows:
WEBCAL_DEBUG=1 evolution-calendar-factory -w >& logfile
This enables libsoup's logging facility with a log level of SOUP_LOGGER_LOG_BODY.
Address Book Backends
Address book backends run in the evolution-addressbook-factory process. Each address book backend defines its own environment variable(s) to enable debugging output, usually as a simple toggle in the form of FOO_DEBUG=1.
Debugging output for the Google address book backend is enabled as follows:
export G_MESSAGES_DEBUG=all LIBGDATA_DEBUG=255 evolution-addressbook-factory -w >& logfile
This also activates debugging facilities in GData itself, showing raw communication between the Google server and the backend.
Debugging output for the LDAP address book backend is enabled as follows:
LDAP_DEBUG=1 evolution-addressbook-factory -w >& logfile
This follows interactions with the LDAP server. Additionally the LDAP_OPT_DEBUG_LEVEL option is hard-coded to 4.
Debugging output for the CardDAV address book backend is enabled as follows:
CARDDAV_DEBUG=1 evolution-addressbook-factory -w >& logfile
This enables libsoup's logging facilities:
CARDDAV_DEBUG=all or CARDDAV_DEBUG=1 sets the log level to SOUP_LOGGER_LOG_BODY.
CARDDAV_DEBUG=headers sets the log level to SOUP_LOGGER_LOG_HEADERS.
All other values set the log level to SOUP_LOGGER_LOG_MINIMAL.
Note that versions before 3.33.1 used WEBDAV_DEBUG environment variable instead of the CARDDAV_DEBUG.
Evolution Source Registry
The evolution-source-registry has muted debugging output since 3.12.9/3.13.8. It can be enabled with:
ESR_DEBUG=1 evolution-source-registry >& log.txt
GNOME Online Accounts
The evolution-source-registry can be also run with special debugging output for GNOME Online Accounts (GOA) since 3.29.1. It can be enabled with:
GOA_DEBUG=1 evolution-source-registry >& log.txt
GOA messages are prefixed with [EDS-GOA] and they usually contain also date and time when they had been printed.
You can force Evolution to be in online mode and ignore the system's connectivity status.
You can also debug the spam filtering (via SpamAssassin or Bogofilter), for example when it behaves incorrectly:
To enable logging of filters on console from command line (not by editing GSettings), which is available since Evolution 3.26.0, use:
Exchange Web Services (EWS)
Debugging output for Exchange Web Services (EWS) is enabled for any above evolution processes. It logs raw communication between evolution-ews and the server, thus eventually exposes private information like message contents, email addresses and such. To enable full logging use:
EWS_DEBUG=2 evolution >& logfile
It can be limited to protocol headers only with EWS_DEBUG=1 .