On Wed, Feb 20, 2019 at 03:38:41PM -0800, Russ Allbery wrote: > Josh Triplett <j...@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.
