Up until a few days ago Fedora automatically went into sleep mode after a period of no input, but in the last few days it has been shutting down instead. I’ve checked the settings as below, but they don’t stop it powering down. Is there something else I need to set too?
F38, KDE Plasma, HP desktop.
Thanks.
The configuration file that controls that behavior is /etc/systemd/sleep.conf (or an override configuration file under /etc/systemd/sleep.conf.d). Use man systemd-sleep.conf to read more about the possible config values.
But if you haven’t changed that file recently yourself, it seems more likely that your system is powering off due to a power fault (e.g. a battery that is reporting that it is almost dead).
@glb thanks for the quick response.
I haven’t changed that file, I didn’t know it existed. I’m just a humble user, so not very technical. It’s a desktop PC, so no battery. The only other thing I can think of is a momentary power failure, but then if that happens all our clocks reset themselves to midnight as well, and that hasn’t happened recently.
All the entries in sleep.conf are commented out. There is no sleep.conf.d directory under /etc/systemd. The man file mentioned some other drop in libraries, so I checked them too, but couldn’t find anything. So it seems the options specified in the “energy saving” window are maintained somewhere else?
Confusing. 
Sorry, I’m not that familiar with KDE specific configuration files. It looks like there is a powerdevil KDE application that may give you access to some additional settings. You should be able to install it on Fedora Linux with the following command:
sudo dnf install powerdevil
If it is something that just changed/broke on its own recently, it might be a bug that has been introduced with an update. Most of the code that manages the system hardware (i.e. the “drivers”) are in the “kernel” software package. Fedora Linux keeps the three most recent versions of the Linux kernel installed to make it easier for users to go back to previous versions in case a new one introduces a new bug. You might try selecting an older kernel during system boot (unfortunately, Fedora Linux hides the boot menu by default these days 
). I think you can still get the boot menu to show by holding the SHIFT key while booting, but it may take a few tries.
Beyond that, if no one else replies here with an answer, there is a chat room where the KDE power management experts hang out. You might try asking your question there: https://chat.fedoraproject.org/#/room/#energy-efficiency:kde.org
If you do find that it is a problem that has been introduced with a new kernel, please do report it using Red Hat’s bugzilla (and specify what hardware you are using) so the problem will get fixed.
Thanks!
Are you sure it is actually shutting down and not simply refusing to (fully) wake? I ask because I just noticed this comment in the Fedora Kernel chat room:
main problem I have with 6.3.10 is laptop has problems coming back from suspend. It resumes but the screen is black. It turns out it successfully suspended but it takes a VT switch and back to Alt-F2 to display the desktop again.
Does that workaround work for you? (i.e. pressing Ctrl+Alt+F3, then Ctrl+Alt+F2 to wake the display)
@glb thanks again for the quick response.
No, it’s definitely rebooting. I have multiple Linuxes installed, and use Refind boot manager to load them. So when I power up, the first screen I see is Refind, and this is what happens after I have I have put Fedora into sleep mode for a long time (like overnight). So it’s definitely rebooting. Then everything is fine, it all works. Although it does tend to run like a dog with one leg for the first ten minutes or so. I assume it’s doing updates or something, as some other weirdnesses sometimes occur as well, like spontaneously logging out, or the cursor disappearing. But most of the time, sweet as a nut.
The only thing that I can think of that might cause that sort of behavior is the systemd-oomd service (oomd = out of memory daemon). It will kill processes to try to keep the system running if it detects that there isn’t enough RAM for whatever processes are currently running. It’s mainly expected to kill things like browser tabs that have bad code using up too much memory and such. But it is certainly not beyond the realm of possibility that it is killing your entire login session or some other system process that is then causing your PC to reboot. If that’s what’s happening, then either your PC simply doesn’t have enough memory (RAM) for what it is trying to run or there is a bad program on your Fedora Linux installation that is “leaking” memory until the system fails/reboots.
The journal will gave recorded the log messages before the system rebooted.
You can see the jouenal for the previous boot with
$ sudo journalctl -b -1 | tail -n 100
That, i think, will show you the last 100 log messages.
If it is a reboot under control then that should be clear in the logs.
If the logs look like business as usual then i would suspect a hardware issue.
You can also grep the output of that journalctl command to look for str8ngs like oom, reboot that may point at the reason for the problem.
@barryascott Thanks for the reply.
I ran the journalctl command, and the results were interesting. I don’t understand much of it, but there are many, many messages about stopping things and ending things. There are thousands of error messages from PipeWire like this
ul 05 09:05:39 Fedorian pipewire[1552]: spa.alsa: front:0: snd_pcm_mmap_begin error: Streams pipe error
I may have been running spotify at the time, or playing a youtube video. But it seems something has definitely gone haywire. I outputed it all to a text file but I can’t figure out how to upload the file. It’s a thousand lines long, can I paste it into a post?..
:-\
You could. But another option that many people use is fpaste. To use it, just pipe whatever you want to share into it and it will return a URL that you can share here. I.e., something like the following:
$ sudo journalctl -b -1 | tail -n 100 | fpaste
One advantage of using that is that your data won’t be online permanently (as long as no one makes a copy of it right away).
Yeah, there are a lot of pipewire errors early on in that log. It does seem likely that those are causing things to fail later on due to resource starvation. Also, a quick internet search shows that someone just reported that recent versions of pipewire can cause 100% CPU resource usage when resuming from suspend:
https://bbs.archlinux.org/viewtopic.php?id=287001
I wonder if simply downgrading pipewire would provide a temporary workaround until the problem is resolved upstream?
You can check your current version of pipewire with the following command.
$ rpm -q pipewire
You can downgrade pipewire with the following command.
$ sudo dnf downgrade pipewire
You will need to reboot immediately after downgrading pipewire (and ideally you should probably do the downgrade from “runlevel 3” if you know what that means).
If that resolves the problem, then you’ll just need to wait for the next version of pipewire to be released before updating it again.
@glb thanks for that. Not sure if that’s my issue though. I just restarted my system from sleep mode, after about 2 1/2 hours, and it didn’t reboot, just resumed normally. I did do one small change however. In the energy saving screen i had unset the “While asleep, hibernate after a period of inactivity” check box. I’ll try resetting it, and then leave it for another couple of hours while I do something a bit more productive with my time.
Just to be sure to be sure, I’ve downgraded pipewire too. It’s now at 3.67-1.
Well, two hours later it resumed normally from sleep mode. I had the “While asleep, hibernate after a period of inactivity” check box on, and it seems to have worked. At least it didn’t reboot. Maybe downgrading pipewire did the trick. I’ve marked the post where that was recommended as the solution.
Thanks again for the help sorting out this issue, much appreciated.