[Uberphallus]

Not related to all binary logging, but journalctl is incredibly sluggish.

Some combinations of slow (rotating) media, certain filesystems, and underpowered CPUs (ARM in my experience) and you get a barely usable logging system that makes you want to punch your box.

[mrweasel]

I'm not currently using Linux, so I might be wrong, or misunderstanding what you're trying to do, but could you just have journald write to syslog?

ForwardToSyslog=yes in /etc/systemd/journald.conf.

[rakoo]

I don't even have an esoteric setup and every time I want to read logs I'll have to wait 30 secs. Even though there is absolutely no activity.

[toupeira]

Try "journalctl -e" or "journalctl --since today", it seems like by default it will load all available logs which leads to this slugishness.

[perlpimp]

it is slow because log is read written in a block binary format but pager accepts byte granular fseek feature to go forward without loading everything into $PAGER's buffers.

[rakoo]

See ? People complaining before reading TFM. Thank you !

[vidarh]

Sounds like you're running into some bug. I've never run into any perceptible lag.

[the_mitsuhiko]

That sounds odd. Did you try to strace it and see what it actually does?

[pgl]

I found this to be the case as well. Especially on a busy system where there are a lot of events, when you're trying to find the cause of an issue and constantly opening and closing logs, the lag is definitely noticeable.

[the_mitsuhiko]

To be honest: that's kinda to be expected if you run it on a slow machine. However you can configure it to be in-memory only and forward to syslog and you have it as it was before.

[XorNot]

I'm highly suspicious that syslog can actually be faster in such a situation. If you can't seek to the disk quickly, then it doesn't matter what you do - logging will be slow if you need to flush frequently.