Syslog messages during reported downtime

I just installed TrueNAS Community Edition on a spare mini-PC and had a strange crash around 17:55. The details of the crash are unimportant—I think one of my RAM sticks was going bad—the important thing is when it happened.

System reporting shows downtime starting about 17:47 and ending at 18:05.

However, there are several messages in /var/log/syslog from during that reported period of downtime:

Aug  2 17:40:03 truenas systemd[1]: Starting sysstat-collect.service - system activity accounting tool...
Aug  2 17:40:03 truenas systemd[1]: sysstat-collect.service: Deactivated successfully.
Aug  2 17:40:03 truenas systemd[1]: Finished sysstat-collect.service - system activity accounting tool.
Aug  2 17:50:04 truenas systemd[1]: Starting sysstat-collect.service - system activity accounting tool...
Aug  2 17:50:04 truenas systemd[1]: sysstat-collect.service: Deactivated successfully.
Aug  2 17:50:04 truenas systemd[1]: Finished sysstat-collect.service - system activity accounting tool.
Aug  2 17:55:04 truenas systemd[1]: Cannot find unit for notify message of PID 5180, ignoring.
Aug  2 18:05:03 truenas syslog-ng[2312]: syslog-ng starting up; version='3.38.1'
Aug  2 18:04:21 truenas kernel: Linux version 6.12.95-production+truenas (root@tnsbuilds01.tn.ixsystems.net) (gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Wed Jul 22 16:39:01 UTC 2026
Aug  2 18:04:21 truenas kernel: Command line: BOOT_IMAGE=/ROOT/25.10.5@/boot/vmlinuz-6.12.95-production+truenas root=ZFS=boot-pool/ROOT/25.10.5 ro libata.allow_tpm=1 amd_iommu=on iommu=pt kvm_amd.npt=1 kvm_amd.avic=1 intel_iommu=on zfsforce=1 nvme_core.multipath=N
Aug  2 18:04:21 truenas kernel: x86/split lock detection: #AC: crashing the kernel on kernel split_locks and warning on user-space split_locks

Does anyone know why this might have happened? Does the uptime reporting just not have enough granularity to catch the exact time the system crashed?

This isn’t unique to TrueNAS. This is the Linux kernel’s usual best-effort attempt to log as much of the circumstances before and after the crash as possible. This is usually asynchronous to the actual event timestamps, as the kernel doesn’t have any guarantees syslog is running, file systems are mounted, or time is actually correct.

I see, so you’re saying the logs with timestamps from 17:50 to 17:55 were probably written after the crash and reboot?

Yes, exactly.

Makes sense, thanks!