On Tue, 2020-02-04 at 18:10 -0800, Russ Allbery wrote: > It does take a bit of retraining to use journalctl instead (and I'm > personally not horribly fond of its UI, although that's probably > because I'm using it wrong), but it's a lot better at effectively > narrowing log messages to the things of interest once you get used to > it.
journald has nits I mention below, but I was prepared to put up with them and drop rsyslog until one day a server stopped in a nasty way and journalctl refused to display what lead up to the crash because it's binary logs were corrupt. As far as I was concerned this made journald unfit for use on production servers. (rsyslog's logs also get 4k lumps of nulls and other garbage in them in similar situations, but they remain usable.) That was a long time ago, and it may well be fixed now. But if it isn't IMO turning off rsyslog by default is a bad idea. My view is the main reason Debian exists is to serve as a reliable base for production machines. Debian Desktop is what I use on my personal machine and yes, dropping rsyslog hardly matters there, but I wouldn't be using Debian Desktop if I wasn't using Debian in production. Another journald anti-feature (which is probably an unfair attribution as it is almost certainly a consequence of systemd's design), is a manually started service doesn't print the reason it refused to start to stderr. Having to fire up journald and wade through it's crappy UI to get something sysV used to put under my nose is a step backwards. Finally, it may be I just don't know how to use it well, but looking for a needle in a haystack of logs is slower with journalctl that it is with grep, and not by a small margin. Journald making the thing you spend most time doing with logs slower doesn't help it in the slightest. But I don't spend a lot of time searching logs, so it wouldn't stop me from dropping rsyslog. Get rid of those problems, and dropping rsyslog becomes a no-brainer for me.
signature.asc
Description: This is a digitally signed message part
