Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

journald is still very, very slow. As in, getting the entries for a given process can take a minute or more, whereas just grepping a normal text file is nearly instant. It doesn't help that the default rotation settings are insane (like, why would using a certain percentage of my total space be fine, what if all programs thought that?).

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.



This... is just not true. I use journald extensively on a 600Mhz Cortex-A9 daily and it's not slow. I don't know what kind of log load you have, but even when I have processes crashlooping and am sending logs over SSH over a VPN it's fine.


The systemd journald test is the longest one on my 3 GHz Power9 system, nearly timing out:

    1475/1475 systemd:libsystemd / test-journal-verify                                    OK              28.44s
but on x86 it runs in under 1s. Not sure the deal there.


I'm not familiar enough with the POWER ISA or POWER9 systems to have any idea what's going on there, but that is surprising.


Hey everyone, it worked on his machine so it's actually not a problem and anyone who has a problem is lying or stupid. Glad that's cleared up.


That's not even remotely what I said.


He's talking about reading logs not writing them.


So am I?


> like, why would using a certain percentage of my total space be fine, what if all programs thought that?

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.


> 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.


What problems?


For me, literally everything it does is a problem, including:

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.


> For me, literally everything it does is a problem, including:

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?


First, i'm a vocal systems appreciater. But. The one thing that frustrates me about the journal is that there is only one journal. If I have a chatty app, it can entirely take over the journal. Set a 1GB hour al, come back in a couple days, and nothing else is left in the journal other than it logging. I hate this so much.

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.


Check out the LogNamespace option.


Why? Why must someone check out a new more complicated way to do something that was already simple by default before logs were turned into db rows?


Bro no. Logrotate shit was gross and gnarly. Every service has its own way of doing with logs. None of it worked the same. It never was simple it always had been crap.

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: