Hey guys. I’ve been having an ongoing problem with my desktop where, when it goes into suspend, it’ll shut down instead of waking back up. Not a hard shutdown, either, but what appears to be a proper shutdown where everything gets nicely SIGTERM’d and everything.
Now, I’m saying all that just in case it’s related to what happened today. I stepped away from my machine after having it play Youtube videos through the night and came back to it about an hour later to find that it had been shut down. There was no indication of an improper shutdown, either, since the usual “hey, you hard powered off and now your disk needs to be fsck’d” messages weren’t there. The logs stop right before when I assume the shutdown happened, but there’s nothing in them that really sticks out as a possible reason for why it would have happened.
Getting to the point, is there somewhere other than journalctl and dmesg that I should be looking to try and figure out what happened? I’m on Fedora 43, and I’m happy to provide whatever logs are necessary. I’m really hoping it’s not a hardware fault, but I’ve had other problems that seem to indicate the PCIe port on my motherboard starting to go bad such as inexplicable static on one monitor and my GPU disconnecting whenever my cat jumps down from my lap too hard.
When this happens to me I mostly assume Linux shutdown automatically because of a critical over temperature event. I’ve seen it in the logs a few times but I don’t usually check anymore.
There’s an example of this here https://unix.stackexchange.com/questions/502226/how-do-you-find-out-if-a-linux-machine-overheated-before-the-previous-boot-and-w
Unless you took a backup I guess it’s not relevant anymore but if it happens again you can narrow down files last changed around some timestamp like so:
find /var -mmin +4 -mmin -5I always forget that
findis that flexible. Thanks.In the offchance that shenanigans are afoot, some malware will fudge mtimes (but not always ctimes) to prevent detection.
If you get files showing up as changed with
-cminbut not modified with-mmin, that’s a bright red one.
Which logs did you look at already?
If you’re using journalctl, I think you should have shutdown messages in the log. You might need to filter by the previous boot for them though (https://linuxhandbook.com/journalctl-boot-logs/).
For dmesg, you might have old, rotated logs from previous boots in your /var/logs folder.
I’d expect any logs around power management to end up in one or both of those places.
You could also try manually triggering a suspend or hibernate to see what happens. I remember having a machine that would suspend fine, but if it was suspended too long, it would hibernate. And for some reason it didn’t know how to come back up after a hibernate.
The last few weeks I’ve had a similar problem and I can’t find a solution. Same installation of manjaro for around 7 years. I made no system setting changes. All I do is update the system with the package manager. When I check some systemd logs or dmesg it all looks normal except from wake it mentions something about an unresponsive disk, but it always works fine after the second wake or if I just shut it down and then boot it up. It’s only a problem from suspend to wake. I can type in my password and log in but it pretty much seems after 10 seconds it suspends itself again for the first time.
Does it happen at a consistent time or frequency? Like at 8pm or after 2 hours of being turned on?
I think I’m just going to keep an eye on it and see if it happens again, since this is the first time it’s ever shut itself down unprompted like this. My cat has also figured out where the power button is and likes to press it occasionally, so unless it happens again I’m just going to chalk it up to that. Might replace the PSU just for good measure, since it’s getting kinda old and was made by EVGA, about whose reliability I’m entirely ignorant.
journalctl -b -1will show you the logs from the previous boot.journalctl -k -b -1will do the same for the kernel logs. If you’ve rebooted again since, just use -2 instead of -1.Even better do
journalctl -r -b -1to get the latest logs firstOr you can just do
journalctl -r --since "5min ago"if it just happened



