Re: Unifying logging by default
Josh Triplett <josh@joshtriplett.org> writes:
> Both syslog and journald support multi-line log messages
syslog does not support multi-line log messages in any reasonable way. It
just escapes the newline (if you're lucky) and jams all the lines
together, and is rather likely to break whatever log parser you have on
the other end.
> Again, I'm aiming for the common case here, and I expect this to be a
> years-long effort, not an overnight one.
I think what's missing for me is what you're trying to accomplish with
this thread. Are you just trying to make people aware of this as
something we *could* do and get people thinking about it in the
background? Are you forming a team of people who is going to tackle this
problem in Debian and are looking for volunteers? Are you asking
packagers to do work today? Are you asking for the project as a whole to
reach some consensus that this is something we should do?
If you're asking whether that sort of work seems like a good idea to other
people, I personally think it probably does for line-structured logs with
no performance issues (and that are actually logs, not execution traces or
data dumps or some other thing -- see below), but the devil is going to be
in the details, and blindly dumping existing log messages into syslog
without thinking a little about how they're structured is not a good idea.
In other words, I think this requires some per-package thought and
analysis. But I previously made this change (relative to upstream
behavior) for the logging from shibboleth2-sp, and that seems to have been
a good idea, or at least not a bad idea.
If you want to get things to change, you're probably going to have to
start doing the required work (or recruiting people to do so), which means
something closer to "I have identified the following 14 Debian packages
that are currently logging to files, have investigated why this is the
case, believe that they would be equally happy logging to syslog for the
following reasons, and here are diffs to make that change."
I suspect you're not going to get a meaningful consensus in advance that
this is something we should do with just an abstract write-up, but may get
traction with an inventory of packages in Debian that currently log to
files and a plan for how to deal with them. Down that path is
(potentially, if successful) a Lintian check to discourage introduction of
new cases, possibly with some carefully crafted exceptions, but I think a
more comprehensive analysis would be needed first.
Not everything in /var/log is a log in the syslog sense, though. I see
some logs that I as a system administrator do not want in syslog and would
be quite unhappy if they were just dumped into syslog because they're pure
noise and I'd then have to filter them out again in my log analysis
pipeline. /var/log/fontconfig.log is an excellent example. That appears
to be a local debugging trace log for fontconfig that I suspect has only
one user (reportbug when filing bugs against fontconfig, if it even knows
to grab that log) and is otherwise pretty useless. So I don't think that
should go into syslog, and it would cause me work if it did.
Another example is /var/log/popularity-contest. I don't think that's
actually a log; it looks like data that popularity-contest gathered. I
definitely do not want that dumped into my syslog.
Maybe you could start with Xorg.0.log. :)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: