-
Thomas Haller authored
Choose a new logging format. - the logging format must not be configurable and it must be the same for all backends. It is neat that journal supports additional fields, but an average user still posts the output of plain journalctl, without "--output verbose" (which would also be hard to read). Also, we get used to a certain logging format, so having different formats is confusing. If one format is better then another, it should be used for all backends: syslog, journal and debug. The only question is, what is the best format. - the timestamp: I find it useful to see how much time between two events passed. The timestamp printed by syslog doesn't have sufficient granularity, and the internal journal fields are not readily available. We used to print the timestamps for <error>, <debug> and <trace>, but ommited them for <info> and <warn> levels. We now print them for all levels, which has a uniform alignment. - the location: the "[file:line] func():" part is mostly redundant and results in wide lines. It also causes a misalignment of the logging lines, or -- as I recently added alignment of the location -- it results in awkward whitespace and truncation. But the location is really just necessary because our logging messages are bad: "<debug> [1456397604.038226] (9) 11-dhclient succeeded" The solution to this is not "<debug> [1456397604.038226] [nm-dispatcher.c:358] dispatcher_results_process(): (9) 11-dhclient succeeded" but a properly worded message: "<debug> [1456397604.038226] dispatcher: request #9, script 11-dhclient succeeded" - logging-message: we need to write better logging messages. I like some form of "tags" that are easy to grep: "platform: signal: link changed: 4: ..." Downside is, that this is not nice to read as a full sentence. So, especially for <info> and <warn> logging, more human readable messages are better. We should find a compromise, where the log message explains what happens, but is still concise and contains patterns that are easy to grep and identify visually. https://mail.gnome.org/archives/networkmanager-list/2016-February/msg00077.html
24582b65