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 withjournald.conf

Then, it's just about usingjournalctl -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, buteventually 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 likeLaurent Bercot'sredirfd orthe nosh toolset'sfdredirExecStart=/usr/local/bin/fdredir --write 1 /run/dmesg.boot dmesg.

Substitutejournalctl -k if you want to snapshot the systemd journal rather than just the kernel's log, and make this aType=oneshot service. Either make it wanted bymulti-user.target or make it aDefaultDependencies=no service that is wanted bybasic.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 feedalone and logs to a private log directory. That takesa 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 asfifo-listen andklog-read, orsocklog. Piping the output through a log daemon that writes to a private, reliably size-capped, auto-rotated, log directory comes as standard with adaemontools/runit/s6/nosh/perp managed service.

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

DESCRIPTION

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

  – UVV

  2016-11-14 16:02:36 +00:00

  CommentedNov 14, 2016 at 16:02
• @UVW that property is shared by classic setups withlogrotate (or syslog built-in rotation). journald is no different in that respect.

  sourcejedi

  – sourcejedi

  2016-11-14 16:28:08 +00:00

  CommentedNov 14, 2016 at 16:28
• 3
  @UVV message expiry is configured injournald.conf; probably best to review its manpage.

  derobert

  – derobert

  2016-11-14 16:29:06 +00:00

  CommentedNov 14, 2016 at 16:29

• systemd
• systemd-journald