Because the journal’s role in a system is inherently different than most programs. It’s collecting logs for everything; not just itself. It seems reasonable to me that a system-wide service would use a percentage of the system’s resources.
Plus, if you don’t like it, reconfigure it. It’s only the default, after all.
Or -- and I know this is crazy but hear me out here -- if you don't like it, and it brings nothing but problems to the table, just don't use it at all.
The file format is not text, and I use it under Linux, which is good at processing text files.
The command line arguments are insane.
Bad handling of log lines emitted at system crash.
Broke an entire prod network’s observability stack because ubuntu replaced syslogd with it in the middle of an lts support cycle.
Brings in a systemd dependency, which causes 100x more problems than this.
That makes it sound that your main problem is the fact that it exists.
> Broke an entire prod network’s observability stack because ubuntu replaced syslogd with it in the middle of an lts support cycle.
That's more ubuntu's fault I guess. I don't really remember this happening though.
> Brings in a systemd dependency, which causes 100x more problems than this.
Is it other made up problems or real things?
1475/1475 systemd:libsystemd / test-journal-verify OK 28.44s
but on x86 it runs in under 1s. Not sure the deal there.If I could assign some apps to a secondary journal, or better quota individual services, that would make sure I can keep tabs on my entire system, even when one app is logging heavily.
I have my complaints but not replying on each service to do something special conpatible with each other log rotation system was not a complaint. Having this managed reasonably has been great.
Generally I don't really understand what journald brings to the table. I'm sure there are esoteric setups where the hash chaining thing makes sense, but meh? A lot of things needed fixing and systemd fixed many of them, but everything journals is a terrible user experience for me.