F40 KDE hangs after 25 minutes when idle

[Go Canes]

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.

[Jeffrey Walton]

On Thu, Feb 20, 2025 at 5:46 PM 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.
>
> 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

[Go Canes]

On Thu, Feb 20, 2025 at 7:54 PM Jeffrey Walton  wrote:
> On Thu, Feb 20, 2025 at 5:46 PM Go Canes  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.target
>
> hybrid-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!

[Barry]

> On 20 Feb 2025, at 22:46, Go Canes  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

[Go Canes]

On Fri, Feb 21, 2025 at 2:48 AM Barry  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!

[Tim]

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.

[Go Canes]

On Fri, Feb 21, 2025 at 3:31 AM Tim via users
 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!

[Frank Bures]

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

[Jeffrey Walton]

On Thu, Feb 20, 2025 at 5:46 PM 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.
>
> 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

[Go Canes]

On Sun, Feb 23, 2025 at 4:14 PM Jeffrey Walton  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 :-(

F40 KDE hangs after 25 minutes when idle - SOLVED

[Go Canes]

Problem appears to have been solved by a UEFI/BIOS upgrade.