On Wed, 2019-02-20 at 14:19:02 -0800, Russ Allbery wrote: > Josh Triplett <j...@joshtriplett.org> writes: > > 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. > > I've seen three main reasons why packages do not use syslog: > > * The log data is not line-structured. Example: /var/log/apt/history.log > Dumping that as-is into syslog sounds like an awful idea. This would > therefore block on an upstream feature request to change log formats > first, with all that entails. > > * Performance. Good examples here are Apache and INN, both of which have > per-request logs that are intentionally not line-buffered and are logged > directly to files, since losing some log messages is not as much of a > concern as performance and disk I/O. I've tried to reroute things like > that through syslog in the past, only to find syslog now taking a > substantial portion of all available system resources trying to keep up. > > * The package does its own log analysis. INN again is an excellent > example: it has a bespoke but very comprehensive and incredibly useful > log analysis package that ships with the software and requires access to > the raw logs. Anything that moves those logs out of their expected > locations will break that tool, which is a significant regression for > our users.
* The log data is "chroot" specific. This applies to all of the package management logs. Logging into syslog would by default not do the right thing and would be extremely confusing. I could see adding options for dpkg and u-a, but they would definitely not be enabled by default. > I think you're going to need a much more concrete and specific proposal > with worked examples of how to deal with cases like this. As is, I think > this proposal is much too vague to really discuss, let alone implement. Agreed! Thanks, Guillem
