this post was submitted on 23 Sep 2024
493 points (97.0% liked)

linuxmemes

20703 readers
1185 users here now

I use Arch btw


Sister communities:

Community rules

  1. Follow the site-wide rules and code of conduct
  2. Be civil
  3. Post Linux-related content
  4. No recent reposts

Please report posts and comments that break these rules!

founded 1 year ago
MODERATORS
493
submitted 10 hours ago* (last edited 10 hours ago) by [email protected] to c/[email protected]
 
you are viewing a single comment's thread
view the rest of the comments
[–] msage 10 points 3 hours ago (1 children)

What "scares" me the most is the journal... for some reason it takes too long to get specific unit logs, and should anything break down in it, there is no way for me to fix it. Like logging has been solved forever, and I prefer specific unit logs to the abomination of journalctl.

But like unit files are everywhere, and systemctl at its core is a nice cmd utility.

[–] [email protected] 2 points 3 hours ago (1 children)

The thing with journalctl is that it is a database. Thus means that searching and finding things can be fast and easy in high complexity cases but it can also stall in cases with very high resource usage.

[–] [email protected] 3 points 58 minutes ago (1 children)

Thing is that they could have preserved the textual nature and had some sort of external metadata to facilitate the 'fanciness'. I have worked in other logging systems that did that, with the ability to consume the plaintext logs in an 'old fashioned' way but a utility being able to do all the nice filtering, search, and special event marking that journalctl provides without compromising the existence of the plain text.

[–] [email protected] 1 points 53 minutes ago

Plain text is slow and cumbersome for large amounts of logs. It would of had a decent performance penalty for little value add.

If you like text you can pipe journalctl