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. > 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 (r...@debian.org) <http://www.eyrie.org/~eagle/>