Environment Variables

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.

If you use a Flatpak version, make sure to adjust the commands below: Replace the evolution command with flatpak run org.gnome.Evolution . Also make sure the Flatpak sandbox is not running, by executing flatpak kill org.gnome.Evolution first.

Mail Backends

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])*

IMAP

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.

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.

POP3

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.

NNTP

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.

SMTP

CAMEL_DEBUG=smtp evolution >& logfile   # 3.10 or later only

This follows the raw SMTP protocol exchanges with the SMTP server.

Only prior to Evolution-Data-Server version 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

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

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.

CalDAV

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.

WebCal

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.

Google

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.

LDAP

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.

CardDAV

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.

Miscellaneous

You can force Evolution to be in online mode and ignore the system's connectivity status.

GIO_USE_NETWORK_MONITOR=base evolution

You can also debug the spam filtering (via SpamAssassin or Bogofilter), for example when it behaves incorrectly:

CAMEL_DEBUG=junk evolution

To enable logging of filters on console from command line (not by editing GSettings), which is available since Evolution 3.26.0, use:

CAMEL_DEBUG=filters evolution

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 .