4 ms·

I love systemd, I just hate journald. Their built-in pager sucks (text flowing off the screen by default, really?), and logging in binary was a mistake. It do

I love systemd, I just hate journald. Their built-in pager sucks (text flowing off the screen by default, really?), and logging in binary was a mistake. It doesn't integrate nicely into any of the tools I would normally use. tail in particular is pain in the ass because I have to wait for journalctl to convert the entire log back to text. Logs are text, tools that work on logs expect text, and I don't give a crap that my logs are 50% smaller or whatever. Disk space is absurdly cheap, and logs are a minority of my disk usage. I know it can forward to syslog, but at that point I'd rather just have syslog. systemd is fantastic, though. I've just been building a new system and having to deal with journald is a big pain in the butt.

nolist_policy 3y ago
From the log producing side, journald is much better than log files. No one wants to manually configure log rotation for each daemon individually (What signal does this daemon use to reopen its log file shudder). With systemd you just log to stdout+stderr and are done.
- throw0101b 3y ago
  > No one wants to manually configure log rotation for each daemon individually (What signal does this daemon use to reopen its log file shudder). I do. I want my (e.g.) auth.log rotated regularly and kept forever. Many other things I only care about (say) 4-6 weeks of retention. (This is in addition to off-host log shipping, which of course journald doesn't do itself so I have to run rsyslog regardlesss.)
- everforward 3y ago
  I would totally agree with this. I'm often both the producer and consumer though, and the consumer side is painful enough I tend to avoid journald. From the producer side, I typically use a logging library/extension that handles its own log rotation and doesn't require logrotate. It's a half-dozen lines of code or so, not too onerous.
charcircuit 3y ago
The logs are stored in a database. Having a database being purely clear text makes querying it slow.
- Ckirby 3y ago
  this is nonsense you can process millions of lines of plaintext in a tenth of a second using awk
- everforward 3y ago
  Their current database is still dramatically slower than log files. Waiting for journalctl to produce logs is consistently the slowest part of me working with my logs. It's just a silly use of a database. I could probably count on my fingers the number of times I wanted non-sequential log records, and that's the only time I can see a database beating log files. Even if I want non-sequential records, Linux has a plethora of tools to manipulate and query plain text that everyone already knows. I would much rather use grep or awk or another tool I know than learn whatever arcane query syntax journalctl supports.
throw0101b 3y ago
> logging in binary was a mistake. They could have at least not re-invented the wheel: perhaps use SQLite (or OpenLDAP's LMDB) instead of DIYing it. > The gory story begins with their journald discussion, here http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/6922/focus=6950 http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/69... where they rationalize why they created their own data structure rather than using an existing embedded DB. Aside from their claim that nothing suitable existed being wrong (LMDB belies those claims) the fact is the solution they developed is inherently unreliable https://bugs.freedesktop.org/show_bug.cgi?id=64116 https://bugs.freedesktop.org/show_bug.cgi?id=64116 which utterly invalidates their claimed attention to robustness. * https://www.linkedin.com/pulse/20140924071300-170035-why-you-cannot-trust-lennart-poettering-systemd https://www.linkedin.com/pulse/20140924071300-170035-why-you...

nolist_policy 3y ago

From the log producing side, journald is much better than log files. No one wants to manually configure log rotation for each daemon individually (What signal does this daemon use to reopen its log file shudder). With systemd you just log to stdout+stderr and are done.

throw0101b 3y ago
> No one wants to manually configure log rotation for each daemon individually (What signal does this daemon use to reopen its log file shudder). I do. I want my (e.g.) auth.log rotated regularly and kept forever. Many other things I only care about (say) 4-6 weeks of retention. (This is in addition to off-host log shipping, which of course journald doesn't do itself so I have to run rsyslog regardlesss.)
everforward 3y ago
I would totally agree with this. I'm often both the producer and consumer though, and the consumer side is painful enough I tend to avoid journald. From the producer side, I typically use a logging library/extension that handles its own log rotation and doesn't require logrotate. It's a half-dozen lines of code or so, not too onerous.

charcircuit 3y ago

The logs are stored in a database. Having a database being purely clear text makes querying it slow.

Ckirby 3y ago
this is nonsense you can process millions of lines of plaintext in a tenth of a second using awk
everforward 3y ago
Their current database is still dramatically slower than log files. Waiting for journalctl to produce logs is consistently the slowest part of me working with my logs. It's just a silly use of a database. I could probably count on my fingers the number of times I wanted non-sequential log records, and that's the only time I can see a database beating log files. Even if I want non-sequential records, Linux has a plethora of tools to manipulate and query plain text that everyone already knows. I would much rather use grep or awk or another tool I know than learn whatever arcane query syntax journalctl supports.

throw0101b 3y ago

> logging in binary was a mistake. They could have at least not re-invented the wheel: perhaps use SQLite (or OpenLDAP's LMDB) instead of DIYing it. > The gory story begins with their journald discussion, here http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/6922/focus=6950 http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/69... where they rationalize why they created their own data structure rather than using an existing embedded DB. Aside from their claim that nothing suitable existed being wrong (LMDB belies those claims) the fact is the solution they developed is inherently unreliable https://bugs.freedesktop.org/show_bug.cgi?id=64116 https://bugs.freedesktop.org/show_bug.cgi?id=64116 which utterly invalidates their claimed attention to robustness. * https://www.linkedin.com/pulse/20140924071300-170035-why-you-cannot-trust-lennart-poettering-systemd https://www.linkedin.com/pulse/20140924071300-170035-why-you...