On Wed, Feb 20, 2019 at 02:03:08PM -0800, Josh Triplett wrote: > While there are *absolutely* configurations in which system > administrators want to log to arbitrary locations and files, I would > like to propose that for consistency we should configure software to > unify logging into syslog and/or journald by default. In particular, I'd > propose that daemons and applications should default to logging to > syslog (working with any installed syslog implementation providing > /dev/log), and that daemons run via systemd units may detect or be > configured to log to stdout/stderr which will be wired to the sysadmin's > preferred log target.
To suggest a more concrete proposal, I'd propose the following rough sketch of future logging policy (not to be incorporated into Policy until after packages generally start following it): - If the software has a well-established set of logfile analyzers specific to its logfile location and format, and the most commonly used logfile analyzers do not support reading data from syslog or journald, the software MAY continue using standalone logfiles (instead of or in addition to the below behavior) until that changes; alternatively, such logfile analyzers MAY facilitate the user's configuration of the software to log to a location they understand. - The software MAY (but is not required to) detect that it is running with stderr or stdout connected to journald, and in that case, log to stderr or stdout, optionally using structured logging. The software MAY detect that /dev/log is connected to journald, and in that case, log to journald directly if it has such support. If the software does not support any such detection, any systemd unit file invoking it SHOULD pass an explicit command-line option enabling logging to stderr. - Otherwise, if /dev/log exists, the software SHOULD log to /dev/log. The software MAY choose to use a structured log format if supported. - Otherwise, the software SHOULD choose an appropriate fallback behavior, such as logging to a standalone file, or displaying log messages to the user if running interactively. Some concrete use cases: - Running logs through a log analyzer. - Shipping logs over the network to an off-machine logging infrastructure. - Controlling where log messages go using syslog configuration. - Logging to an in-memory journal on a system without persistent storage.
