This is mostly conjecture, I’ll say up front, but off the top of my head it sounds like your system is trying to hibernate (suspend-to-disk). But then that process fails, so instead of going into sleep mode it immediately proceeds to the resume state — which, since there’s no hibernation file to restore, turns into a normal boot sequence.
The out-of-order timestamps lend weight to that possibility, and probably mean the system clock isn’t set correctly — the system would boot up logging the timestamps it got from the BIOS clock up until the point where it was able to load chronyd
(the network time daemon) and update the clock with the correct time.
You can probably check that second hypothesis, at least, by viewing sudo systemctl status chronyd.service
— if you can see a time shift around when the service starts up, or there’s a line like System clock TAI offset set to N seconds
with some huge value of N
, then chronyd
is responsible for the time jumps in the log.
(Losing time during suspend is also a common thing, with the clock time being updated on resume and a sudden time jump happening in the logs, but that usually only goes forward and if my first theory is correct you aren’t really spending any significant time in suspend state anyway.)
Providing details on your system type (laptop, desktop, etc.), manufacturer, age, etc. might be helpful in solving this. I’ve definitely seen the whole “attempt to enter hibernation state turns into an immediate reboot” thing on desktops plenty, even these days. Laptops are usually a lot better at the whole power-management thing, so it’d be more surprising there.
Either way I’d also recommend checking the BIOS / UEFI setup for any sort of settings related to power management / hibernation / etc. to see if perhaps something’s enabled at the hardware level. (Though it’s unlikely that would’ve happened only upon upgrade to F30, granted.)
As far as the SIGTERM
thing, though, at least on Fedora 31 that’s actually a red herring. It appears a few seconds into every startup on my system, as odd as that seems:
Dec 14 03:10:49 kernel: microcode: microcode updated early to revision 0x2f, date = 2019-02-17
Dec 14 03:10:49 kernel: Linux version 5.3.15-300.fc31.x86_64 (mockbuild@bkernel03.phx2.fedoraproject.org) (gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)) #1 SMP Thu Dec 5 15:04:01 UTC 2019
Dec 14 03:10:49 kernel: Command line: BOOT_IMAGE=(hd0,msdos4)/vmlinuz-5.3.15-300.fc31.x86_64 [etc...]
-----8<-----
Dec 14 03:10:49 systemd-journald[297]: Journal started
Dec 14 03:10:49 systemd-journald[297]: Runtime Journal (/run/log/journal/5593b6f732944ad491ba36d3b37def31) is 8.0M, max 396.0M, 388.0M free.
Dec 14 03:10:49 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-journald comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 14 03:10:49 kernel: audit: type=1130 audit(1576311049.113:2): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-journald comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 14 03:10:57 systemd-journald[297]: Journal stopped
Dec 14 03:11:08 systemd-journald[297]: Received SIGTERM from PID 1 (systemd).
Dec 14 03:11:08 kernel: audit: type=1131 audit(1576311067.844:32): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-journald comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 14 03:11:08 kernel: audit: type=1130 audit(1576311068.139:35): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-journald comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 14 03:11:08 kernel: audit: type=1131 audit(1576311068.139:36): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-journald comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 14 03:11:08 systemd-journald[654]: Journal started
Dec 14 03:11:08 systemd-journald[654]: Runtime Journal (/run/log/journal/5593b6f732944ad491ba36d3b37def31) is 8.0M, max 396.0M, 388.0M free.