Using DLT (http://projects.genivi.org/diagnostic-log-trace/home) would make a lot of sense. For example, more detailed debug logging and retrieval of the results could be done via DLT. Details TBD.
Here's how SyncEvolution and libsynthesis support DLT now, code about to be merged into master branches: README-DLT.rst: Diagnostic Log and Trace ======================== Diagnostic Log and Trace (DLT) is a logging mechanism defined and implemented by GENIVI: http://projects.genivi.org/diagnostic-log-trace/ SyncEvolution optionally supports DLT as follows: * syncevo-dbus-server, syncevo-dbus-helper and syncevo-local-sync can log to DLT. Operations with "syncevolution --daemon=no" never use DLT. * Each of the three processes uses a different application ID. By default, these IDs are "SYNS", "SYNH", "SYNL". These default can be changed via configure options. All processes use just one context, with the fixed ID "SYNC". * syncevo-dbus-helper and syncevo-local-sync only run occasionally. This makes is hard to adjust their log levels, for example via the dlt-viewer, because the processes and their contexts are only shown (known?) while the processes run. To work around this, the initial log level of these two helpers are inherited from the log level of the "SYNC" context in syncevo-dbus-helper. * That log level defaults to "WARN", which ensures that normal runs produce no output. * To enable DLT support during compilation, use "--enable-dlt" and "--with-dlt-syncevolution=SYNS,SYNH,SYNL" where SYNS/H/L are the actual application IDs. * To enable DLT support at runtime, run syncevo-dbus-server with "--dlt". Logging to syslog should be disabled with "--no-syslog". * The hierarchical log from libsynthesis gets flattened into a flat stream of messages and no syncevolution-log.html files are written. README.DLT: GENIVI Diagnostic Log and Trace (DLT) support ============================================= DLT is a logging mechanism defined by GENIVI. It supports the context of log message contexts (arbitrary groups, defined by the app or library) and levels (off, fatal, error, warning, information, debug, verbose). The log level can be set per context, using mechanisms provided by DLT (for example, interactively via DLT client connected to a system running the DLT daemon and apps using that daemon). If DLT support is enabled during compilation of libsynthesis (use --enable-dlt on Linux) and in the configuration (use "dlt" as "logformat" and ignore all other logging options), then libsynthesis uses DLT for logging instead of writing its own files. libsynthesis has no concept of a strictly ordered log level. Instead major categories are combined with minor ones, which allows enabling "more verbose" logging for some aspects of a major category while leaving "less verbose" ones disabled. When using DLT, a hard-coded mapping between minor categories and log level is used, so some flexibility is lost. The mapping is as follows: Context ID = Synthesis debug topic: description (from SySync_config_reference.pdf) PROT = "proto": SyncML protocol related information. SESS = "session": Session management related information. ADMN = "admin": Everything that has to do with administrative data (anchors, targets, map table). DATA = "data": Everything that has to do with handling user data (data objects). Actual user data will however be shown only if loglevel >= debug. REMI = "remoteinfo": This shows information delivered in the remote party's device information, such as manufacturer name, datatypes supported, fields supported etc. PARS = "parse": This shows information related to parsing and processing incoming data from the remote party. Actual user data will however be shown only if loglevel >= debug. GEN = "generate": This shows information related to generating outgoing data for the remote party. Actual user data will however be shown only if loglevel >= debug. TRNS = "transp": Shows transport (http and TCP communication) related information. SMLT = "syncml_rtk": Messages generated by the SyncML Toolkit code. SYSY = "rest": Any other debug log message that does not fit in any of the above contexts. The default log level of each context can be set via env variables called LIBSYNTHESIS_<context ID>, with values from 0 (off) to 6 (verbose). The log level of a message is derived from the other Synthesis debug topics: "error" => ERROR: error messages. "hot"=> INFO: most important information (of all topics). This should never be switched of (except when switching off debug logging completely). "userdata" => DEBUG: Anything that is user data. To create anonymized logs that do not show user's data, use a log level less than debug (and, depending on the database interface, "dbapi" as well, as it might show SQL commands revealing user data as well). "dbapi" => VERBOSE: Information related to accessing the database. For ODBC, this enables showing SQL statements issued to the database, for plugin datastores, this includes all communication with the plugins and also messages generated by the plugin itself (see "plugin" below). "plugin" => DEBUG: Messages generated by database adapter plugins. "scripts" => VERBOSE: This is useful to debug scripts, and shows each line of executed scripts (but only for enabled debug topics!). Switching this on can generate huge log files, so it should normally be switched off in productive environments. "expressions" => VERBOSE: Together with "scripts" this causes detailed step-by-step logging of script expression evaluation. "filter" => DEBUG. Information about data item filtering. "match" => VERBOSE: Information about matching data in slow sync. Note that together with "exotic" this can produce extremely large logs as matching is an O(N^2) operation, so use with care. "conflict" => DEBUG: Information about conflict resolution and data merging. "details" => increases log level by one. Enabling this option adds generally some more detail to the debug output. "exotic" => VERBOSE: Enabling this adds the highest level of exotic detail possible. This is usually only required to track down device interoperability issues or bugs in the server/config.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.