What is the system sleep status immediately exiting the keep.running context manager?

[reidswanson]

I am basically wondering about the situation where the system is configured to sleep after being idle for x minutes (e.g., 10 minutes). Wakepy then inhibits sleep for x+1 minutes. Does the system immediately go to sleep after exiting the keep.running context manager or is the system idle timer also reset, so the system won't actually go to sleep for another x minutes after exiting? Is the behavior dependent on which operating system / desktop environment being used?

[fohrloop]

What an interesting question! I haven't even thought about that previously. The answer unfortunately is that since wakepy is "just a wrapper around system APIs", the answer depends on the operating system and desktop environment (and their versions) used.

I would have guessed that for example org.gnome.SessionManager would hold a wakelock only until the lock is released, but it actually seems to reset the sleep timer periodically, and will leave the system with zeroed-out sleep timer (so with automatic sleep after X minutes you would have to wait X minutes after keep.running context manager is exited to make the system sleep automatically):

org.gnome.SessionManager test

Tested on Ubuntu 22.04.4, Gnome 42.9 using instructions in How to test wakepy Modes? and

• set automatic sleep in Gnome settings to 600 seconds
• ran the following to prevent sleep for 550 seconds

>>> import time
>>> from wakepy import keep
>>> with keep.running() as m:
        print(m.used_method)
        time.sleep(550)

• Logged the timings with the wakepy test script, and saw deltas of 2 seconds until 1137 seconds (18:57min):

...
Jun 17 09:28:05 | elapsed 0:18:57.365266 | delta: 2.001891s
Jun 17 09:32:44 | elapsed 0:23:36.825433 | delta: 279.460167s
Jun 17 09:32:46 | elapsed 0:23:38.827872 | delta: 2.002439s
Jun 17 09:32:48 | elapsed 0:23:40.830495 | delta: 2.002623s
Jun 17 09:32:50 | elapsed 0:23:42.831480 | delta: 2.000985s

I started the timer (test script) perhaps 5-20 seconds after the wakepy keepawake script. Taking the 550 out of 1137 gives 587 seconds, so the system started sleeping after ~600 seconds after the 550 second wait, and the org.gnome.SessionManager did leave the system with "zeroed" sleep timer after exiting the context manager (after uninhibit).

Do you think adding information about the idle timer reset to the returned Mode instance would be useful? What kind of use case you have?

[reidswanson]

Thanks for the quick response and the mini test was exactly the type of information I was looking for. Somehow I missed the testing section in my first pass through the documentation. I'll have to run the same experiment on my system to see what happens.

AFAIK, Windows will prevent your system from sleeping if it is active, but there is no such mechanism in Linux, which has bugged me for years. There are tools like Caffeine, but I basically always forget to enable them when I need to, so I don't find them very useful. At one point I found a script that more or less had the functionality I wanted but it basically only worked with Gnome and systemd. Unfortunately, I use KDE and OpenRC.

Long story short, I've been happily using wakepy with a scraping project, so I thought I'd spend a couple days writing my own system utilization monitor script to prevent the system from sleeping under significant utilization.

As a bit of a side note this comment intrigued me:

and the org.gnome.SessionManager did leave the system with "zeroed" sleep timer after exiting the context manager (after uninhibit).

A long time ago, before I discovered wakepy, I scoured the web trying to find any information about the sleep timer/idle timeout counter in KDE and whether it could be reset, e.g., using dbus. At the time I couldn't find anything about it at all. Nothing about how to retrieve its current value or how to reset it. So, I find it interesting that it can at least be done with Gnome.

[fohrloop]

I'm pleased to hear you've enjoyed using wakepy - and KDE is actually the latest addition, only a bit more than two weeks old! The system utilization monitoring script seems like a cool project. Do you think you can continue with the information you got (on KDE when using org.freedesktop.PowerManagement, when exiting the context manager, the sleep timer will be set to zero) ?

Are there action points or feature requests raising from this? Perhaps should document something like "The idle/sleep timer is set to zero when exiting the context manager unless otherwise specified"? I'm guessing it's quite safe assumption. But I've never seen any documentation on any of the APIs I use which would explicitly say this!

[fohrloop]

Now that I've thought this a bit.. Probably all desktop environments (or: power managers) work like this: They have a idle/sleep timer(s). When the timer goes over a threshold, they will do a function call which puts the system into sleep. Now if you inhibit this action, what are the practical ways implementing it? It's probably either "set a flag which prevents sleep" or "reset the idle timer" (see below for examples).

the two practical ways to implement inhibitor

a) will leave the timer unresetted after exiting the keepawake, and b) will zero the timer before exit.

a) Prevent sleep with a flag (no timer resets)

automatic_sleep_threshold = 600
timer_value = 0 

while True:
    time.sleep(1)
    timer_value += 1
    if user_activity_detected():
        timer_value = 0
        continue
    elif timer_value > automatic_sleep_threshold:
        call_sleep()


def call_sleep():
    if inhibit_flag_set(): # check the flag here
        return
    # go to sleep

b) Reset the timer

automatic_sleep_threshold = 600
timer_value = 0 

while True:
    time.sleep(1)
    timer_value += 1
    if inhibit_flag_set(): # check flag here and reset timer
        timer_value = 0
        continue
    elif user_activity_detected():
        timer_value = 0
        continue
    elif timer_value > automatic_sleep_threshold:
        # go to sleep

Now if you think about the inhibitor, there are two kinds of them: The ones inhibiting idle action (inhibit starting screensaver and going to sleep) and ones inhibiting just sleep. I'm not sure which came first, but I would guess the first actual "inhibitor" was the human user. Whenever mouse or keyboard is used, system knows that it should not do the idle action. The way it is inhibiting idle action while someone is using the system must be the timer-zeroing method as setting some sort of flag in this case does not seem practical (you would need a separate timer for the flag then). I'm just guessing again that when someone decided to create an API for prevent the idle action, they just implemented it like the inhibition coming from the human actions: using the "reset the timer" method. I mean, most likely, because it was only a small change to do it. With this, it seems more likely that all systems have it implemented this way. But of course it's still possible that there are exceptions :)

[reidswanson]

Yeah, I should be able to continue now that I have this information. If I ever publish it, I'll post a note here, but be forewarned it will be pretty rudimentary.

I think it would be helpful to have a short note in the documentation along the lines you've suggested, if for no other reason than it will be the only place on earth it is documented anywhere ;-)

I agree that it makes much more sense from an ease of implementation point of view to just reset an idle timer, but since I haven't ever seen it documented anywhere I didn't want to rely on untested assumptions.

[reidswanson]

Just a quick update. I ran the test script on my system and it also appears that in KDE keep.running will reset the idle/sleep timer. I set my system to go to sleep after 5 minutes and kept the system awake for 260 seconds using keep.running. The system did not go to sleep until 9 minutes and 14 seconds after starting the inhibit script (roughly 5 minutes + 260 seconds).

[fohrloop]

Could you also add the version of KDE used and the used method (I assume it was org.freedesktop.PowerManagement)? Just for possible need in the future to reference this comment.

[reidswanson]

The method was org.freedesktop.PowerManagement

Using:
X11
KDE Plasma: 5.27.11
KDE Frameworks: 5.116.0

[fohrloop]

Thanks! I suppose you used the keep.running mode (and not the keep.presenting) ?

[reidswanson]

Yes, that is correct (keep.running).

[fohrloop]

The PR 472 added a Post Keepawake Behavior page to the documentation which explains the different alternatives. It also added the behavior under the Methods in the Wakepy Methods page (currently documented for Windows 10, Windows 11, GNOME using org.gnome.SessionManager and KDE using org.freedesktop.PowerManagement)