Desktop failing to sleep every "2nd time"

Ask Fedora
, ,
1

Hi everyone,

Not sure how to fix this so I’ll cave in and ask here. If I have used any wrong terminology or if this sounds confusing, feel free to ask more questions or correct me.

The problem:
This only started happening a few weeks ago out of the blue. My computer has no problems going to sleep (either by suspend or hibernate) after booting from a powered off state. However, after I wake up the computer from its sleep and later attempt to put the computer to sleep again (so putting it to sleep for the 2nd time since the last fresh boot), it locks up indefinitely and I am forced to just hold the power button to turn it off.

Symptoms:
There are no problems or any unusual aspects until I try to put the computer to sleep a 2nd time. This is what happens then:
The desirable:

  • All inputs and outputs cease to respond (keyboard, mouse, audio playback, etc)
  • Network disconnects
  • All hardware lights go off

The undesirable:

  • The screens go blank; not entirely off, just a blank screen.
  • All fans continue running exactly as they were prior to putting the computer to sleep, going on eternally (or at least until I can no longer wait before forcing a shutdown). This is what tells me it never actually goes to sleep, just enters some blank state.
  • Doing anything to try waking up the computer does nothing at all (pressing power button, etc.)

What I’ve tried so far:

  1. Reading the journalctl to diagnose.
  • There are no entries or lines indicating any issues when trying to sleep. The last line before I just go ahead and shut off is simply “localhost.localdomain kernel: PM: suspend entry (deep)”.
  1. Performed “sudo swapoff -a” and “sudo swapon -a” just in case it was a memory swap issue.
  2. Performed “systemd-inhibit --list” to see if there were any blockers. All I have in here are the following:
    ModemManager (delay), NetworkManager (delay), UPower (delay), PowerDevil (block) and Screen Locker (delay).
  • Since I’m on KDE that might not mean anything, but could PowerDevil be the culprit here?
  1. Changed the lock screen SDDM and themes just in case that was doing something.
  2. Tried to check out the /etc/systemd/sleep.conf file. It contains the following:
    [Sleep]
    #AllowSuspend=yes
    #AllowHibernation=yes
    #AllowSuspendThenHibernate=yes
    #AllowHybridSleep=yes
    #SuspendMode=platform suspend
    #SuspendState=mem standby freeze
    #HibernateMode=shutdown
    #HibernateState=disk
    #HybridSleepMode=suspend platform shutdown
    #HybridSleepState=disk
    #HibernateDelaySec=3600
  • Is the above configuration the culprit? If not, is it still how it should be?
  1. Tried a variety sleep methods including pressing the power button on the desktop, clicking “Sleep” in the menu, and even a number of systemctl and pm commands to both suspend and hibernate. No luck.

That’s as far as I can get diagnostic-wise, but does anyone know of any other files, settings or logs that could help provide more clues or even an outright solution to help the computer actually go to sleep? Is there a possible clue in that it only happens the 2nd time onwards?

Thanks for taking the time to read; any help would be much appreciated!

2 Likes
2

Just an update - tried another simple fix, to just run the following commands (rebooting for the second one):

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

sudo systemctl restart systemd-logind.service

sudo systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target

Now I was able to run “sudo systemctl suspend” twice in succession and it didn’t lock up. Not sure why that may have fixed this issue but just in case it still persists, I’ll report back if it still occurs.

This just means I am going to have to suspend using the command rather than any software/hardware buttons for now but whatever works.

1 Like
3

Guess I spoke too spoon, the issue still occurs when putting the computer to sleep after a long period (at least a few hours) since the last time it’s woken up.
This time around, there is one journalctl entry that has my curiosity after starting the suspend:

localhost.localdomain loginctl[314085]: Failed to issue method call: Unknown object ‘/org/freedesktop/login1/session/auto’.

Is this related in any way?

1 Like
4

May have found an answer. Running the following successfully lets the computer suspend:

sudo su
echo mem > /sys/power/state

This appears to suspend to ram and although it isn’t to hibernate, it does at least let the computer sleep without crashing, just takes around 15 or so seconds before it entirely goes to sleep. I’m assuming this means suspend to ram works in this manner whilst suspending/hibernating to disk doesn’t for some reason.

I got the idea to run the above command by reading this: Debugging hibernation and suspend — The Linux Kernel documentation

Will post here again if it fails in the near future, otherwise it’s looking good.

2 Likes