Investigating why a diskless client (booted over NFS) crashed, I noticed that: $ mount -o nolock,ro <nfs-server>:/nfs/<clientroot> mnt $ journalctl -b -0 -D mnt/var/log/journal took almost 6 seconds before showing the log. The NFS 'server' is a consumer grade router with a hard disk attached to its USB port, resulting in reasonably slow transfer speeds, but which are otherwise acceptable for its intended purpose. From experience with a few other systems, startup time for journalctl increases as the number of boots recorded and the journal size increases. I believe this may be due to the high number of disk accesses required to find the beginning of entries pertaining to the last boot in the journal. This bug report is a request for improving the access speed of specific boot journal entries.
Update: after suffering a graphics driver issue on my main desktop, I noticed that: $ journalctl -b -1 took almost 40(!) seconds to begin displaying log entries. (As may be obvious, this machine has rebooted lots of times, and the journal dir takes up quite a lot of disk space.)
If journalctl is to seriously take on the competition of logrotated syslog, then IMHO fixing this delay should be high priority. In some cases (the proverbial printer being on fire, but in particular CPUs overheating in a server rack, etc), quick access to the logs is very important.
same issue, systemd-215
Does this patch help? http://lists.freedesktop.org/archives/systemd-devel/2015-April/030050.html
Jan Janssen's patches that improve this have been merged now. Hence closing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.