Fedora Restarting Sporadically Overnight or During Periods of Non-Use

Ask Fedora
1

Every so often my system restarts without any reason

This only occurs overnight or when I am away from the computer for more than a few hours
I come back expecting everything to be as it was, but instead I find a freshly rebooted system

I cannot seem to find the root cause of this issue

I’ve been having this issue since I installed Fedora on this system

Examining journalctl I can find this particular entry that seems interesting but it doesn’t give me any insight as to why it is occurring

Dec 09 03:53:57 ---- systemd-journald[340]: Received SIGTERM from PID 1 (systemd).

As an aside, journalctl seems to be out-of-order… For instance as I scroll down I see Dec 8, Dec 9, and then Dec 8 again… what is with that? At any rate…

What steps can I take to at least set things up such that I can figure out why this is occurring next time it occurs?

1 Like
2

I have been using Fedora Core 29 (recently upgraded to 30) for several weeks.

Almost every night my computer seems to restart for no apparent reason.

While I am using it, zero problems, but in the morning when I go to my desktop I discover the machine has unexpectedly rebooted. This has happened nearly every night, with no apparent pattern.

I tried looking through journalctl and am having trouble reading it… the log seems to be out of order, the date goes from Dec 8 to Dec 9 and then back to Dec 8 again… makes it difficult to ascertain what is going on…

I do notice one log entry that seems to be a flag for me

Dec 09 03:53:57 _____ systemd-journald[340]: Received SIGTERM from PID 1 (systemd).

Would this be the root of the issue? How can I solve it? What steps can I take to further debug and trace the issue?

Thank you kindly for any advice or pointers.

3

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.
1 Like
4

On the last point, it is interesting that SIGTERM is issued on every startup. I’m sure there is a good reason for it.

At any rate, running the chronyd.service stauts command I get the following:

Dec 16 06:58:51 jsxfed chronyd[1185]: System clock TAI offset set to 37 seconds
Dec 16 06:58:51 jsxfed chronyd[1185]: System clock wrong by 1.042132 seconds, adjustment started
Dec 16 06:58:52 jsxfed chronyd[1185]: System clock was stepped by 1.042132 seconds

Is this N = 37 considered a huge value?

At any rate, the software side of things may not be the problem. I observed the other day that my cat went and pressed his nose to the tower causing a small static jolt, and when he did this the computer shut-off. Interesting, I thought. Later, I placed a piece of metal on top of the tower for an un-related reason, and the computer instantly shut-off.

I’m pretty sure the motherboard is improperly grounded or insulated, or something along those lines. I will look further into the system clock thing if you think it is also important, but first and foremost, before investigating more software solutions, I am going to take apart the desktop and ensure it is properly grounded/insulated from the case (and give it a thorough cleaning - it’s about that time).

Thank you for very much for your detailed reply and ideas.

PS - are you aware of any way I could have the system automatically suspend to disk at regular intervals so I could restore the system quicker when it does happen to restart? I won’t get around to cleaning for several days and my average uptime is ~2 days these days, and it would be less frustrating if I could quickly un-suspend as opposed to totally reboot and lose everything I have open.

5

I wanted to provide an update and see if anyone else has any ideas to help me out.

The problem has gotten slightly worse.

It reboots while I am using it. For no apparent reason, randomly, the system does a hard reset.

It is extremely inconvenient. It happens approximately 1-2 times per day.

How can I determine the cause?

6

This looks like a hardware issue.
I’ve seen multiple similar problems caused by a faulty power unit.
Sometimes, it can also be caused by faulty RAM or motherboard capacitors.

7

This is what I fear. The system runs very smoothly other than this issue.

Is there any way I can determine which hardware component could be the culprit?

Would there be any logs or diagnostics available within Fedora to help diagnose this issue?

1 Like
8

I’ve added a few links above, but it is generally not easy to localize and fix problems like this without compatible spare parts and/or soldering.

9

Thank you for the links. I am aware of what a PSU is, I’m just not sure how to test it for such an odd, intermittent issue.
I am also aware of memtest86, and will give it a run.

I was not aware of the capacitor plague! Thank you for that - very interesting. My unit is from 2017-2018 I believe, so I am likely not affected by that.

I really hope it’s something basic like improper grounding - I don’t have the funds at the moment for costly repairs or replacements.

10

As an aside, does anybody know of some “harm reduction” techniques by way of being able to quickly restore my work?

Something that could automatically hibernate my system every few seconds so if I suddenly and utterly lose power I lose very little work would be idea.

Does something like that exist?