3 ms·

Not related to all binary logging, but journalctl is incredibly sluggish. Some combinations of slow (rotating) media, certain filesystems, and underpowered CPU

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.

pgl 12y ago
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.
rakoo 12y ago
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.
- vidarh 12y ago
  Sounds like you're running into some bug. I've never run into any perceptible lag.
- the_mitsuhiko 12y ago
  That sounds odd. Did you try to strace it and see what it actually does?
- toupeira 12y ago
  Try "journalctl -e" or "journalctl --since today", it seems like by default it will load all available logs which leads to this slugishness.
  - perlpimp 12y ago
    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 12y ago
    See ? People complaining before reading TFM. Thank you !
mrweasel 12y ago
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.
the_mitsuhiko 12y ago
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 12y ago
  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.

pgl 12y ago

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.

rakoo 12y ago

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.

vidarh 12y ago
Sounds like you're running into some bug. I've never run into any perceptible lag.
the_mitsuhiko 12y ago
That sounds odd. Did you try to strace it and see what it actually does?
toupeira 12y ago
Try "journalctl -e" or "journalctl --since today", it seems like by default it will load all available logs which leads to this slugishness.
- perlpimp 12y ago
  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 12y ago
  See ? People complaining before reading TFM. Thank you !

mrweasel 12y ago

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.

the_mitsuhiko 12y ago

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 12y ago
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.