I am building up my system from a minimal install of Fedora 35, using the Everything iso.
I use LightDM as a display manager and light-locker to lock the session. I use Awesome as my window manager.
Using the default X settings, my screen locker will lock my screen and put my monitor in standby if the system has been idle for 10-15 minutes, as expected. I’m using the default X and light-locker settings for this. What I’m looking for is the ideal way to implement some other power management features. Specifically, I would like to have the system automatically suspend if it’s been idle for 30 minutes or an hour.
For other users that run Fedora from a minimal install, I am looking for a good method of doing this that is easy to implement in my environment and doesn’t add anything to my systray or install a bunch of dependencies for a desktop environment I’m not using. And I want to use something available in the Fedora repositories.
The system I’m using is a desktop PC, not a laptop.
Hi usually I use
xset only to disable system suspend with my i3wm. But turn out it also can also can manage the suspend. let say delay 30min then
xset dpms 0 1800.
xset dpms delaystandby delaysuspend delayscreenoff
You can check your current setting with
xset q and find DPMS values.
Here I found a good tutorial on how to use
How about just configuring
IdleActionSec=30min in /etc/systemd/logind.conf? See man
Have you done this before with a system? This would be a great solution assuming it will work the way I am expecting it to. That is, that when I leave my system idle, light-locker will still lock the screen and put the monitor in standby like it does currently after 10 minutes, and then systemd will suspend the system automatically after 30 minutes.
Is anyone aware of any reason I should avoid using this method? It doesn’t seem like it would conflict with anything on my system, and seems easier to work with than acpid, which might be the only other option that meets my criteria.
With what @firecat4153 suggested look like more minimalist than
xset. You could check Github light-locker here on part Usage.
I use this method currently on my laptop to automatically suspend in conjunction with xss-lock to lock the screen and perform a few other pre suspend actions.
I modified my config for systemd/logind.conf and it wasn’t suspending on idle. It seems nothing in my environment is providing the idle hint that systemd requires to handle this correctly.
xss-lock is providing this for your system, so I am going to install it and have it autostart in my AwesomeWM session to run
light-locker-command -l to lock the system. I will update this thread after I’ve tried this.
Ah yes, xss-lock is probably the missing piece. I set it up quite awhile ago so details were a bit fuzzy
Here’s an update in case anyone finds this thread in search. I’ve decided to reconsider having my system automatically suspend. To @firecat4153 and @oprizal, you don’t have to read this long post. Thank you for your help.
I checked the man page for
light-locker and figured out how to enable the idle hint. I tried a few different options for the locker, including late locking and not locking on suspend. In any case, when logind would trigger the idle action (
suspend), something—most likely the fact that the screen was already locked when the x screensaver kicked in—was inhibiting the system from going to sleep. The display would come back on at the display manager/lock screen, and I could unlock the session, where networking would be disabled and things wouldn’t be working right. The system would require a hard reset to get it working again.
This might be a bug with
light-locker; there were Github issues for it related to problems if the lock command was issued twice. My experience left me feeling like the screen lockers weren’t intended to lock the session for the x screensaver and then handle the ACPI event from systemd.
I suspect that I could have gotten this working with
xss-lock. I did install
xss-lock, and in an instance where I told it to ignore sleep, the system did properly suspend. In this test case, the screen never locked because I didn’t have a running instance of
light-locker. I could potentially resolve this with having
xss-lock run a simple bash script.
Light-locker is supposed to serve the same purpose as
xss-lock in responding to both screensaver activation and ACPI events. While I feel like I could get them to work together if I script it right, they clearly aren’t intended to be used together and I don’t like idea of forcing such a solution to work and have it be something that runs every time I log into my session. I’ve also realized having the idle action configured for systemd could have issues as well. So, ultimately, I think I’m going to go back to what I was doing previously on this desktop. When I set up a laptop with a similar configuration, I’ll probably install xfce’s power manager.