this would make a great cyber weapon to go along with a backdoor
https://github.com/systemd/systemd/issues/2402
so was it a bug or a weapon triggered at the wrong time
check out Poettering reply oh some programs need access to that
hay dude the programs that need that access to that already provide
the needed access to that by themselves in the same way that ckfs provides it's own mount umount

the users of systemd should thank god that the kernel crew fixed this one

why the binary log files ?
any database format just about can be generated by a program from a human readable text file
for the database formats that can't a hex string can be included to give a more in detailed report
like the error codes from any normal program
my theory there things being deeply hidden in the log file

if systemd had been released by the U.S. Department of Defense as open source
would it have been included in any distro ?
would it have been trusted by anybody ?
BUT
that's exactly where it came from via RedHat

Rob, while I am fully appreciative of that opinion, I can't help but wonder if you are simply suspicious of things that you do not immediately understand. (And, I say that with the utmost respect to you – asking you therefore not to take offense.)

One of the key justifications for "a binary log format" was that sometimes the things that "this-or-that needs to 'log'" are not "intrinsically ASCII." Thus, the log-format does not impose expectations concerning "\n, \r etc." Yeah, this means that you do now need to use special programs to "bust out" whatever log-content happens to be ASCII ... but in so doing it relieves you of the requirement that "the one-and-only thing that we can manage to 'log' is, and must be, ... ASCII."

Today, the "Linux®" environment can no longer assume that every one of the programs that it will be expected to support "were built in the 'Unix® way.'" Neither can they assume that they are "the only machine," such that anyone can afford(!) to spend "only-time" with any of them. Quite the opposite. When your intended deployment is "massively(!) parallel," you quite literally cannot afford to spend time "baby-sitting" any particular node.

Arguably, "this is a radically-different use case." And, it may well be, "it is not a use-case that at-all applies to you." Should this be true, then "you have legacy options that will still work just-fine for you."

Thus, I perceive this to simply be a Robert Frost case: "two paths diverged in a wood."

The folks who "desperately needed this" might consider it to be a god-send ... warts and all. Whereas, your view might be entirely different. Yea, "two paths diverged in a wood."

This post has been reported as personal attacks.

To all LQ members,
Can all members format their replies in a professional manner please?
General forum does allow more leeway but be sure to make arguments based on facts. Make replies based on facts. Please don't throw rocks.

You can be sure the reasoning for binary log files will be put together by the project's marketing people - which of course has no agenda whatsoever...

And that's pretty much how it works these days - one reads several blogs from so called experts and then simply repeats this at every opportunity.

Thompson, Ritchie, McIlroy, Kernighan and Pike had it all wrong, the latest kewl kids and their fans on the various Linux forums have it all right...

I think it's ok to prefer, to like, to love systemd, it may work for you, but it's still crap code born from a crap philosophy and driven purely by commercial necessity. Like it all you want, but crap is still crap, nothing more or less.

DUDE I am about as far as one can get from supporting systemd
I can see no need to make the log files machine readable ONLY
like I said a hex string containing detailed info would have worked
to fulfill any database requirements

my question is
what are they hiding in those binary log files ?

I think your bringing up
AMT is a misdirection from the possibility that systemd has a hidden backdoor

It is possible to disable the persistent logging to the /var/log/journal/ directory if desired. If /var/log/journal/ is removed, it will not be recreated if /etc/systemd/journald.conf is configured with 'storage=auto' is set. If 'storage=none' is set it won't log at all.

From 'man journald.conf'...

And of course plain text logging can still be invoked using syslogd or similar.

Moderator note:
Please avoid personal attacks. They do not add anything valuable to the discussion. Personal attacks aren't allowed on LQ and are against the forum rules.