(16-02-2021, 04:21 PM)venam Wrote: Especially, that it's the subject of the day on IRC because members are working on related projects (freem, mort).

I have not read that thread, yet, but so that people can know a bit more about the projects you're speaking about, bot projects have reached at least alpha stage (mine, at least, for mort's, I don't know, but it seems to be usable, it may even be considered released?):

* mort is writing a log reader, a tool to help understanding logs by highligting some sequences in it.
* freem (me) is writing a monitoring tool, which parse daemon's logs to inform the human behind screen of their status: down, up, or "waking up" in a visual fashion. The last one being "daemon manager started process, but process does not informs that it's up, so let's guess it is after some time".

...

Few hours later, the text is read, and I have to answer, as a systemd opponent myself, I must say that many things there are just... 1970s-style, when a local storage had high cost, and, most importantly, software reliability was a joke (restart manually daemons? Really?).

As a *very important foreword*, let me remind that the words I criticize are from 2016, the author was younger, and I was, too, so maybe I'd have been more friendly to that text. Maybe.

For a start, I'll give some links towards someone else's blog, that I think interesting reads:

* https://asylum.madhouse-project.org/blog...-terrible/
* https://asylum.madhouse-project.org/blog...-terrible/

Regarding content:

> The developers took the leisure to do their own logging
system,to store the logs in a location of their choice, and in a format they conceived.
We can't really discuss these types of logs as the subject is very broad
and the developers can do absolutely whatever they want.

I disagree that "developers can do absolutely whatever they want".
All those methods are normal logging, so it's possible to discuss them. Many, too many daemons in my Debian actually rely one of those methods, and it's a pain.
I'd say, if you find a tool doing that, drop it as soon as possible.

Why?
Because logs are the pain information of your systems. They are critical. If you can't feel the pain, you can't dodge injuries.
Same for a computer: without monitored logs, nothing can prevent damages.

In practice, logs are done in mostly 3 fashions:

1) a mix of stderr/stdout prints
2) printing to a specific file
3) dump on a socket

Case 1 is easy: redirect where you want. That's the best.
Case 2 and 3 are annoying, you need to rely on some tricks to force daemons to put their shit in water-closets. So that you can process it correctly and extract meaningful info. When you can configure it, you can use /dev/stdout for example, but when you can't... just drop the tool, if you can, really. If you can't, place a socket before it starts, or other trick. Raw logs are not very useful to a non-dev.

About the rest, I'll concentrate my arguments into those few words, because it's really, really late:

* a central system does not imply the absence of local, more detailed systems
* a single central system, even if local, implies Denial of Service attacks
* syslogd by default encourages DoS attacks and lack of resilence
* text is binary, when text is not american^Wlingua franca (wait, does franca means, french derived?:p). Which means, it's almost always binary, thus text logs always require 3rd party tools
* even pure 7-bit text, "ascii" encoding requires 3rd party tools to be usable
* binary formats allows control integrity chunk by chunk
* "text formats" relies on underlying binary FS storage anyway, so are binary and unreliable if binary formats are.
* gzipped tarballs are readable by vim and less, are they text formats?
* syslog is a fucking standard. I hate that fact, but it's still true.
* syslog have no security, and can't prevent malicious network user to rewrite logs
* syslog being based on UDP guarantees nothing, you'd better store logs locally
* it's easier to redirect a daemon's stderr/stdout to a file or process when it comes to log analysis, than to grep syslogd or journalctl, and that technic is decades old: daemontools.
* a logging system should have an as most reduced impact on system as possible: not recreating a directory is a feature, here. For reliability reasons.
* binary files can be more flexible than text. Ever tried to grep for all mail addresses?