Re: Unifying logging by default
On Wed, Feb 20, 2019 at 03:38:41PM -0800, Russ Allbery wrote:
> 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.
As far as I can tell, RFC5424-formatted structured messages would
support newlines far better than classical syslog. That said, I'm not a
syslog expert, and I'd defer to those who are.
But in any case, emitting the lines one by one also works for many of
the logs mentioned in this thread.
> > 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?
The most recent mail I sent to the thread has a more concrete proposal,
along with a few sample use cases. In my particular case, I care about
this so that I can configure logging behavior in *one* place rather than
one place per package, as well as being able to view logs in one place
with correlated and consistent timing information, as well as handling
log rotation automatically as part of a logging daemon with no need to
periodically run logrotate.
I'm seeking some amount of consensus, with the understanding that I'm
quite willing to write many patches myself.
My opening mail featured a few of the logs I care about addressing this
for. On my system, they include alternatives.log, aptitude, the various
cups logs, dpkg.log, and fontconfig.log.
> 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.
Even if it were logged at priority "debug"? I would personally prefer to
have that data in journald rather than a standalone file.
That said, for my particular use cases, I care a little less about log
files that are overwritten each time, and I care more about log files
that grow over time.
> 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.
That one is certainly less of an issue. See above regarding files that
get overwritten each time.
(I also wonder if it perhaps belongs in /var/cache, but I'll leave that
to people who use popcon.)
> Maybe you could start with Xorg.0.log. :)
Xorg and the software that invokes it, in conjunction, are already quite
capable of logging to several more useful places, including syslog and
logs in the user's home directory. The default desktop configuration
doesn't generate an Xorg.0.log out of the box.
Reply to: