I have a laptop running F40 Server with KDE, fully updated, that I have been using without issue. I am in the process of moving to a new laptop and plan to repurpose the old one. But I am running into an issue with the old laptop.
If the laptop is idle it locks up after ~25 minutes. "Idle" can mean no one logged-in, or a user logged-in but not doing anything. If the user is doing something, it does not lock-up. "Something" can be running a Windows 10 VM, a ssh session running "top", etc. To recover the system I have to do a hard-reset using the power switch.
Things I have checked: - Nothing is displayed on the screen - There are no entries in the UEFI BIOS logs - There are no messages for the lock-up shown by "journalctl -b -1 -r". - All of the entries in /etc/systemd/sleep.conf have been changed from "yes" to "no" and uncommented - no change - systemctl entries for sleep, suspend, hibernate have been masked - no change - Even though the desktop is KDE, I have checked "gsettings" for any power or timeout related settings - nothing of interest - If I boot off of a F40 Cinnamon install on a USB SSD drive, there are no issues.
Theories: - auto sleep/suspend/hibernate - contraindicated by no change in behavior with changes to sleep[.conf and/or masking system units. Also, system should wake-up from any of these states. - thermal event - contraindicated by lack of UEFI log entries, lack of issue when system is active, lack of issue when booted off of USB drive - hardware issue - contraindicated by lack of issue when system is active or booted off of USB drive.
Any suggestions? The only other thing I can think of to try is a re-install; I plan to do this eventually anyway, but wanted to delay for a few weeks. In the meantime I guess I can keep the Windows 10 VM running, it just seems wasteful.
On Thu, Feb 20, 2025 at 5:46 PM Go Canes letsgonhlcanes0@gmail.com wrote:
I have a laptop running F40 Server with KDE, fully updated, that I have been using without issue. I am in the process of moving to a new laptop and plan to repurpose the old one. But I am running into an issue with the old laptop.
If the laptop is idle it locks up after ~25 minutes. "Idle" can mean no one logged-in, or a user logged-in but not doing anything. If the user is doing something, it does not lock-up. "Something" can be running a Windows 10 VM, a ssh session running "top", etc. To recover the system I have to do a hard-reset using the power switch.
Things I have checked:
- Nothing is displayed on the screen
- There are no entries in the UEFI BIOS logs
- There are no messages for the lock-up shown by "journalctl -b -1 -r".
- All of the entries in /etc/systemd/sleep.conf have been changed from
"yes" to "no" and uncommented - no change
- systemctl entries for sleep, suspend, hibernate have been masked - no change
- Even though the desktop is KDE, I have checked "gsettings" for any
power or timeout related settings - nothing of interest
- If I boot off of a F40 Cinnamon install on a USB SSD drive, there
are no issues.
Theories:
- auto sleep/suspend/hibernate - contraindicated by no change in
behavior with changes to sleep[.conf and/or masking system units. Also, system should wake-up from any of these states.
- thermal event - contraindicated by lack of UEFI log entries, lack of
issue when system is active, lack of issue when booted off of USB drive
- hardware issue - contraindicated by lack of issue when system is
active or booted off of USB drive.
Any suggestions? The only other thing I can think of to try is a re-install; I plan to do this eventually anyway, but wanted to delay for a few weeks. In the meantime I guess I can keep the Windows 10 VM running, it just seems wasteful.
I don't use systemd-sleep.conf(5). Instead, I use the following to mask the services:
systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
This effectively takes power management away from Systemd. The Windows Manager or Desktop Manager will still manage power using their own timers.
If masking the services does not help, then check your BIOS/UEFI settings. Try disabling the S3, S4 and S5 power states.
Jeff
On Thu, Feb 20, 2025 at 7:54 PM Jeffrey Walton noloader@gmail.com wrote:
On Thu, Feb 20, 2025 at 5:46 PM Go Canes letsgonhlcanes0@gmail.com wrote:
- systemctl entries for sleep, suspend, hibernate have been masked - no change
I don't use systemd-sleep.conf(5). Instead, I use the following to mask the services:
systemctl mask sleep.target suspend.target hibernate.targethybrid-sleep.target
As confirmation: sudo systemctl status sleep.target suspend.target hibernate.tar get \ hybrid-sleep.target ○ sleep.target Loaded: masked (Reason: Unit sleep.target is masked.) Active: inactive (dead)
○ suspend.target Loaded: masked (Reason: Unit suspend.target is masked.) Active: inactive (dead)
○ hibernate.target Loaded: masked (Reason: Unit hibernate.target is masked.) Active: inactive (dead)
○ hybrid-sleep.target Loaded: masked (Reason: Unit hybrid-sleep.target is masked.) Active: inactive (dead)
This effectively takes power management away from Systemd. The Windows Manager or Desktop Manager will still manage power using their own timers.
Power setting within KDE is "no action" when on AC power. Power is stable, so it is always on AC power. If there was an issue with AC power, the battery should be drained and the laptop would not be able to boot, let alone stay up for 25 minutes.
If masking the services does not help, then check your BIOS/UEFI settings. Try disabling the S3, S4 and S5 power states.
I will double-check, but I don't think the UEFI BIOS on this laptop provides that level of control, at least not using that terminology.
Thank you for the suggestions!
On 20 Feb 2025, at 22:46, Go Canes letsgonhlcanes0@gmail.com wrote:
Any suggestions? The only other thing I can think of to try is a re-install;
Check that the power settings are the same on the working and not working laptops.
Look in the system journal to see what happens. Do you see any sleep/suspend related service starting up?
You might have a hardware issue? Have checked for dust harming cooling for example? Maybe run a memory test over night to see if that is the issue?
Masking services is not going to help if the system is configured to not sleep of idle.
Barry
On Fri, Feb 21, 2025 at 2:48 AM Barry barry@barrys-emacs.org wrote:
Check that the power settings are the same on the working and not working laptops.
Power settings are as identical as I can make them given differences in the UEFI BIOS. Power settings within KDE are identical.
Look in the system journal to see what happens. Do you see any sleep/suspend related service starting up? You might have a hardware issue? Have checked for dust harming cooling for example?
These were addressed in my original post. TL;DR - no journal entries, no thermal events logged at the UEFI BIOS level, system does not lock-up if something is running such that it is not "idle" - such as booting a Windows VM (which suggests not a hardware or thermal issue).
Maybe run a memory test over night to see if that is the issue?
I have not totally ruled out some sort of memory issue, but I would expect it to be exposed when the system is under more stress, such as when running the Windows VM.
Thank you for the suggestions!
On Thu, 2025-02-20 at 17:45 -0500, Go Canes wrote:
I have a laptop running F40 Server with KDE, fully updated, that I have been using without issue. I am in the process of moving to a new laptop and plan to repurpose the old one. But I am running into an issue with the old laptop.
If the laptop is idle it locks up after ~25 minutes. "Idle" can mean no one logged-in, or a user logged-in but not doing anything. If the user is doing something, it does not lock-up. "Something" can be running a Windows 10 VM, a ssh session running "top", etc. To recover the system I have to do a hard-reset using the power switch.
Check for screensavers. You could have one that is crashing.
On Fri, Feb 21, 2025 at 3:31 AM Tim via users users@lists.fedoraproject.org wrote:
Check for screensavers. You could have one that is crashing.
I don't run any screensavers. Even if I were, lack of lock-up when a Windows VM is running would suggest a screensaver is not the issue.
Thank you for the suggestion!
On 2025-02-20 17:45, Go Canes wrote:
(stuff nuked)
If the laptop is idle it locks up after ~25 minutes. "Idle" can mean no one logged-in, or a user logged-in but not doing anything. If the user is doing something, it does not lock-up. "Something" can be running a Windows 10 VM, a ssh session running "top", etc. To recover the system I have to do a hard-reset using the power switch.
I feel your pain :-)
Some 20 years ago I ran a Beowulf cluster of some 30 nodes with 6-core Athlon CPU in each. One of the nodes would simply stop intermittently and the only way out was HW reset. Once a week to once a month.
We replaced RAM, PSU, disk and Mo-Bo. Nothing helped. There was nothing else to replace. Then I discovered that the node only stopped when it was IDLE. So I installed the BOINC client and let it run on a single core with Nice=19. Problem solved. To this day I do not know what was causing it.
Good luck. There are still too many things between the Heaven and the Earth.
Frank
On Thu, Feb 20, 2025 at 5:46 PM Go Canes letsgonhlcanes0@gmail.com wrote:
I have a laptop running F40 Server with KDE, fully updated, that I have been using without issue. I am in the process of moving to a new laptop and plan to repurpose the old one. But I am running into an issue with the old laptop.
If the laptop is idle it locks up after ~25 minutes. "Idle" can mean no one logged-in, or a user logged-in but not doing anything. If the user is doing something, it does not lock-up. "Something" can be running a Windows 10 VM, a ssh session running "top", etc. To recover the system I have to do a hard-reset using the power switch.
Things I have checked:
- Nothing is displayed on the screen
- There are no entries in the UEFI BIOS logs
- There are no messages for the lock-up shown by "journalctl -b -1 -r".
- All of the entries in /etc/systemd/sleep.conf have been changed from
"yes" to "no" and uncommented - no change
- systemctl entries for sleep, suspend, hibernate have been masked - no change
- Even though the desktop is KDE, I have checked "gsettings" for any
power or timeout related settings - nothing of interest
- If I boot off of a F40 Cinnamon install on a USB SSD drive, there
are no issues.
Theories:
- auto sleep/suspend/hibernate - contraindicated by no change in
behavior with changes to sleep[.conf and/or masking system units. Also, system should wake-up from any of these states.
- thermal event - contraindicated by lack of UEFI log entries, lack of
issue when system is active, lack of issue when booted off of USB drive
- hardware issue - contraindicated by lack of issue when system is
active or booted off of USB drive.
Any suggestions? The only other thing I can think of to try is a re-install; I plan to do this eventually anyway, but wanted to delay for a few weeks. In the meantime I guess I can keep the Windows 10 VM running, it just seems wasteful.
On the old laptop, try changing the chassis type to something other than laptop. I believe you can use hostnamectl to do it. This comes from an old Bay Trail machine that was misdetected, and it had weird power behaviors. See https://www.google.com/search?q=systemd+change+chassis+type. Eventually Red Hat added some logic to detect the Bay Trail machines to work around some of the misfeatures.
Moving forward, buy an inexpensive Intel NUC when you want an inexpensive server. The thing about the NUCs is, Intel provied BIOS/UEFI updates. Eventually power problems get fixed in the firmware so you don't have to putz around with kernel and userland workarounds. On NUCs, you just disable S3, S4 and S5 power states in the BIOS/UEFI and things start working as expected. "Expected" means you can mask systemd services and things stop going to sleep or hibernate on your server.
I've tried other mini-pc machines, like Beelinks. The OEM does not provide BIOS/UEFI updates, so problems never get fixed. Hence the reason I prefer Intel NUCs.
Jeff
On Sun, Feb 23, 2025 at 4:14 PM Jeffrey Walton noloader@gmail.com wrote:
Moving forward, buy an inexpensive Intel NUC when you want an inexpensive server. The thing about the NUCs is, Intel provied BIOS/UEFI updates. Eventually power problems get fixed in the firmware so you don't have to putz around with kernel and userland workarounds. On NUCs, you just disable S3, S4 and S5 power states in the BIOS/UEFI and things start working as expected. "Expected" means you can mask systemd services and things stop going to sleep or hibernate on your server.
This older laptop has been replaced with a newer laptop, so it is *very* inexpensive ;-). The annoying thing is that as soon as I can finish moving some data and processes off of it, I will be re-installing Fedora, but I need it to stay up and running until then. Hence why I will leave the VM running if I can't find any other solution. In the meantime this *might* be a problem someone else could run into, and could even be a problem that will recur even after a re-install, hence my willingness to troubleshoot it - at least to a point.
I have a NUC, but for various reasons it is running Windows. I also had an older NUC that I liked very much until the day it just died without any warning. The only issue with the current NUC is that from time-to-time the screen won't un-blank; when it does sometimes the NUC appears to be hung, sometimes I can tell that it is running backups on a normal schedule. A BIOS upgrade improved things, but it still has the issue. For a brief time I was able to run Fedora on it, and Fedora did not have any problems. But as I said at the beginning of the paragraph, for reasons - Windows :-(
Problem appears to have been solved by a UEFI/BIOS upgrade.