T
@TheRider said:Anybody understands what is happening here? Me neither. But it is important that those programmers can live in the belief that they have implemented thorough logging functionality...
I've found that for most applications, logging is mostly useful for finding things for which to grep through the application source. This should not be the case, IMHO, but it's what I've found. Usually, the older an application is, and the more widely used an application is, the less this is true. For example, sendmail was originally written around 25 years ago, and it's been a couple of years since I saw anything in the sendmail logs that I didn't understand until I went grepping through the source for it. Oh, wait, that's right - I transitioned from sendmail admin a couple of years ago also. Sigh.
(For what it's worth, the vast majority of sendmail logging is decipherable without the source code. But I do find it sad that, after 25 years, there's still bits that require the source to really understand. In my years of sendmail administration, I probably only needed to grep source about a dozen times to understand log files. A dozen times too many.)
However, one can easily contrast this with an in-house application I replaced early on in my prior job. It had been written by one person, who intended to support it for the rest of his career. Sadly, that was over sooner than he expected, and in the next four years, five people supported it and extended it. As I recall, there were two log lines which it could issue that were readily meaningful: "Program started", which was issued whenever someone started the program, and "Program stopped", which would've been issued if someone sent a TERM signal to the program within about 0.1s after the time logged the first message. After that, another signal handler stole the TERM signal for its own use, and never gave it back. The rest of the log messages were far more useless than your sample. I think some of them were quotes from books - 5-6 of them looked very similar to lines from "the Lord of the Flies", for example. And then there were those that were almost useful - for example, sometimes it would log an account name. Each line was date stamped, so one at least had that to go with it, but there were at least four places it could log an account name, and it made no distinction on that line which one did it. And, every so often, it would abort an operation after logging the bit that identified the routine but before logging the account name. That wouldn't have been so bad, except that one of those four places was distinguished by the fact that it didn't log a bit that identified the routine, and the aborts didn't log. (Some did - these didn't. Until after I fixed that, of course.)
Thinking back to horrors like this really makes me appreciate my job, where most of the application logging I need to look at comes from one of three commercial applications which produce very nice logs (at least, relative to both of the examples I've mentioned here), which were straight-forward enough I was able to write a log summarizing routine just from looking over the logs. Since the vendor's finally released text that describes the log format, I've even been able to validate that said parsing was mostly performed correctly. And, for the in-house scripts and applications - well, I'm on the review board for all code changes, and I can veto bad logging. Some has snuck through the process, but it's more like the stuff you've posted, rather than the horrors from my past. And, over time, it gets fixed.