I have a new (to me) lap top and recently installed F36 using ext4 partitions with no swap partition. My laptop is a Dell xps with 16gb of ram and a 512gb ssd. When I close the lid, it appears to suspend, but when I check on it while later the screen is on. So, of course, the battery is being drained.
I think I understand from older comments here and other sources that in order to properly suspend, a swap partition or file is required. i think I can easily steal some space from my /home partition for this. Will this solve the suspend problem?
No, suspend doesn’t require swap, only hibernate(suspend to disk).
If your screen is staying on in the suspend state something else is wrong there.
3 Likes
Shuks. I was hoping I had found the answer. As I said, when I first close the lid, the screen goes off and stays off for a while. Some time later (10 minutes or so) it will likely have come back on ( I check by peeking into the slight opening between lid and keyboard; not by opening). I do have Power Mgmt set to suspend when the lid is closed.
1 Like
I’m still trying to find the answer to this problem of lid closure not suspending the system. I found the following comment:
“Note that the system will not go into a suspended state while users are logged in. You can overwrite the suspend inhibitors with -i option.”
The command “systemctl suspend -i” does work. So, I made a work-a-round by putting a self defined command line launcher applet in my panel that executes that command. So, all I need to do is click on the panel applet and close the lid. The system will suspend and (I think) stay that way until I open the lid.
I’m still trying to figure out why closing the lid alone doesn’t suspend. Is there a config file for the lid closure somewhere?
Follow up:
It appears that I have found the solution. I am running the Cinnimon spin of F36. So, if you are running a different desktop, the answer might be a bit different. On my system the System Settings include a Power Management menu. Within that there is a button for turning on/off Hybrid Sleep. By default it was on. I turned it off and suspend with lid closure now seems to be working as it should.
3 Likes
Where did you read that? I am asking because I think it’s not true. I often just close the lid of my notebook and it goes to sleep (suspend to ram) for hours, without logging out my user before closing the lid.
I believe that text refers to running systemctl suspend, not shutting the lid or suspending via the DE.
1 Like
Sorry. I can’t find the quote again. I can only say that after installing F36, the computer would not sleep (suspend) when closing the lid. The command “systemctl suspend” would cause the screen to momentarily go black, but a few moments later it would come back on even with the lid closed. Using the command “systemctl suspend -i” worked.
As I said, switching off “Hybrid Sleep” has allowed the lid closure to put the computer to sleep as it should. I’m not sure that should be the cause, but that’s OK as I don’t use Hybrid Sleep anyway.
I found it here https://linuxconfig.org/how-to-suspend-sleep-fedora-rhel-system-from-command-line and I think what is meant is “other users”.
I’m glad you got your issue sorted.
1 Like
Thanks. Suspend with lid closure is now working as it should. However, I’m at a loss as to why “Hybrid Sleep” should have been the cause of the problem. It seems like a good switch to have turned on. I do have the Power Manager set to shut down when the battery is critically low. I hope that works.
I believe hybrid sleep is a form of hibernation. It probably requires swap space the same way hibernation does.
Suspend does not have that requirement so for me it seems to make sense that the change would resolve the issue.
Ah. That makes perfect sense. The Hybrid Sleep switch ought to have a warning with it that swap space is required for it to work and the default setting should be off. This because, if I’m not mistaken, Fedora’s default is to use zram rather than a swap partition.
2 Likes
This has been an elusive ever changing issue. After seemingly resolving the issue (above), it recurred after a while. I can’t put my finger on anything that might have caused it. However, almost by accident I discovered that if I move the mouse dongle from one USB port to the other, the problem would go away. It appears that I have a permanent resolution by purchasing a bluetooth mouse eliminating the dongle. It works beautifully (fingers crossed).