I have a systemd/journald running on my board. The system was built by means of yocto; systemd version is 216.

What I want to get is a kernel boot log, which can be obtained with journalctl -k. But as far as I see a long version of this option is --dmesg, which leads me to think that this is retrieved from kernel ring buffer. Obviously if the system runs for days I might no get this information. Is my understanding correct here?

The question is now is there an option for journald to dump this info right after system booted? If not, is it sufficient just to call journalctl -k > dmesg.log as the last step of booting process?

3 Answers 3


Systemd stores everything in its log. Which at least on my laptop on moderate usage is big enough to go back to a year ago with default settings.

Should that not suffice, you can tinker with journald.conf

Then, it's just about using journalctl -t kernel (which is similar to -k, except it also allows you to see previous boots and use filters)


Obviously if the system runs for days I might no get this information. Is my understanding correct here?

Yes. It's dependent from how much log information is generated, but eventually the boot information will scroll off the beginning of both the kernel's ring buffer and the systemd journal. It's no guide to how long it takes on anyone else's systems, but I have systems which have uptimes in the hundreds of days whose boot log data have long since scrolled off the top of the systemd journal. This is one of the disadvantages of having one giant combined log stream that everything fans into and then fans back out from again.

So take a leaf from FreeBSD and NetBSD and their derivatives. They all have services that run once, at bootstrap just after local filesystems have mounted, that simply do:

dmesg > /var/run/dmesg.boot

Thus a snapshot of the kernel log as it was at bootstrap is available in /var/run/dmesg.boot even if it has since scrolled off the actual logs.

You simply need to write a systemd service that does the same. Use the shell for redirection,

ExecStart=/bin/sh -c "exec dmesg > /run/dmesg.boot"
or use something like Laurent Bercot's redirfd or the nosh toolset's fdredir

ExecStart=/usr/local/bin/fdredir --write 1 /run/dmesg.boot dmesg

Substitute journalctl -k if you want to snapshot the systemd journal rather than just the kernel's log, and make this a Type=oneshot service. Either make it wanted by multi-user.target or make it a DefaultDependencies=no service that is wanted by basic.target. Note that it does not have to be ordered after local filesystem mounts (i.e. local-fs.target). That ordering is necessary for FreeBSD and OpenBSD because /var/run could be a disc filesystem with them. On systemd operating systems /run is an "API filesystem" that is created at bootstrap before any services.

(The approach that I personally prefer is not to have the giant central log stream in the first place. A dedicated service feeds off the kernel log feed alone and logs to a private log directory. That takes a lot longer to reach the point where last bootstrap information scrolls off the top. And it also contains boot logs from prior boots.

However, this is a lot more complex to set up in a systemd world than a oneshot that writes a /run/dmesg.boot. It is simple in a daemontools family world, though. It's a trivial exercise in the use of tools such as fifo-listen and klog-read, or socklog. Piping the output through a log dæmon that writes to a private, reliably size-capped, auto-rotated, log directory comes as standard with a daemontools/runit/s6/nosh/perp-managed service.)


Kernel logs are copied into the systemd journal. You don't need to do so manually.


systemd-journald is a system service that collects and stores logging data. It creates and maintains structured, indexed journals based on logging information that is received from a variety of sources:

· Kernel log messages, via kmsg

  • 1
    Is systemd journal also ring buffer based? I.e. if the journal size exceeds its maximum, will the old messages be discarded?
    – UVV
    Nov 14, 2016 at 16:02
  • @UVW that property is shared by classic setups with logrotate (or syslog built-in rotation). journald is no different in that respect.
    – sourcejedi
    Nov 14, 2016 at 16:28
  • 3
    @UVV message expiry is configured in journald.conf; probably best to review its manpage.
    – derobert
    Nov 14, 2016 at 16:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.