3 ms·
journald is IMO the worst part of the systemd ecosystem. You're better off using it only as a router and not storing any logs in it. The indexing system it uses
by barrkel 2mo ago
journald is IMO the worst part of the systemd ecosystem. You're better off using it only as a router and not storing any logs in it. The indexing system it uses is slow and provides no control over chatty subsystems - you cannot truncate the logs for just a single identifier. For all the use indexing is doing you will get better performance out of a modern grep like ag or rg. Structure is worth something but it's better off somewhere other than journald.
- graemep 2mo agoI recently put a lot of effort into reducing logging because of excessive writes. It was so much easier when everything had its own log and you could just look at which files were growing.
- e2le 2mo agoI would much rather that they had used an existing database file format. Sqlite3 is robust and already present in the default installation of most Linux distributions. Querying system logs with SQL would be cool and likely faster than using the sd_journal API with all it's weird quirks.
- deleted 2mo ago[deleted]
- Walf 2mo agoText or text-like (e.g. text content with simple control char delimiters for metadata) would be far superior than the slow-down from Sqlite's safety mechanisms. Optimising logs for read, at the expense of write, is a bad pattern to me.
- tomjakubowski 2mo agoThere's an open source project which is a syslog daemon that stores logs in DuckDB. You can configure journald to forward logs to it. https://github.com/phare/sloggo https://github.com/phare/sloggo
- xorcist 2mo agoIf you want to store logs in a database, just use standard rsyslog. It has supported database backends pretty much since its inception at the dawn of the century. No need to reinvent anything.
- DaSHacka 2mo ago> No need to reinvent anything. Well I think we found the reason for journald's complexity right there, systemd devs and reinventing the wheel (plus breaking backwards compat in the process) is a match made in heaven
- magicalhippo 2mo agoSystemd is touted as being highly modular. So it should be easy enough to replace the logging module journald. Why hasn't this been done if it's that terrible?
- TingPing 2mo agoYou can trivially configure it to forward logs to another service to manage them.
- kasabali 2mo agoBecause it's a big fat lie
- stryan 2mo agoWhile the rest of systemd is actually pretty modular, journald is unfortunately the only other required component. You can not run systemd without journald running in some way; closest you can get is setting Storage=none and forwarding the logs elsewhere. journald is in a weird state where its "good enough" and mandatory that most people forget how bad it is until something like this pops up. Normally I'm pretty happy with systemd and its many components; I even willingly run systemd-resolved, which is probably the other most hated component. But journald makes a lot of weird choices and if I could drop it I would in a heartbeat.