hypridle icon indicating copy to clipboard operation
hypridle copied to clipboard

timer keeps running while sleeping

Open ehula opened this issue 1 year ago • 17 comments
trafficstars

I have one of my listeners set to suspend. However, if I manually suspend (like close the lid), it seems that hypridle's timer keeps running. If I don't resume my laptop until after the suspend timeout period has lapsed, as soon as my laptop finishes resuming, hypridle immediately suspends it again.

Can you either pause the timer while sleeping, or reset the timer or restart hypridle on resume?

This was not a problem with swayidle.

ehula avatar Jun 24 '24 21:06 ehula

Yup, I am facing the same issue.

I tried to inhibit the suspension by using a "lock" file:

on-timeout = cat /tmp/hypridle-lock || touch /tmp/hypridle-lock && systemctl suspend

and

on-resume = rm /tmp/hypridle-lock

And also doing the same when I encounter a lid close event and lid open event.

But it seems like that workaround fails.

saharshbhansali avatar Jul 02 '24 13:07 saharshbhansali

can confirm i'm facing the same issue. this happens on both my desktop and my laptop. suspending and then immediately waking is fine, but waking after a long time of sleep (my sleep timeout is set to 30 minutes) causes the system to immediately suspend again.

muni-corn avatar Jul 05 '24 12:07 muni-corn

And also doing the same when I encounter a lid close event and lid open event.

But it seems like that workaround fails.

I've also tried another workaround, which is to kill hypridle using bindl = , switch:on:Lid Switch, ..., and then run the same commands used in the on-resume section of each listener along with restarting hypridle with switch:off:Lid Switch.

Killing hypridle works, and the timer stops (cause duh), but hypridle doesn't restart, nor do the on-resume section commands seem to run properly.

So, in the end, this workaround appears to fail as well.

saharshbhansali avatar Jul 05 '24 14:07 saharshbhansali

The exact same behavior is occurring to me also. Laptop immediately suspends when I open the lid.

HarshNarayanJha avatar Jul 07 '24 14:07 HarshNarayanJha

I've noticed that if I suspend the laptop manually (by running systemctl suspend) and wake the machine after the timer expires with a key press, it does not immediately suspend again. But if I suspend it by closing the lid, it will suspend again after opening the lid.

My theory is that hypridle does not recognize the lid switch event as activity and does not reset the idle timer when waking the machine by opening the lid.

mike-lloyd03 avatar Jul 13 '24 03:07 mike-lloyd03

Same here. It doesn't always happen, but when it happens it's usually after I've closed the lid and let it go to suspend-then-hibernate and let it go to hibernate 4 hours later. When I resume the laptop from hibernation it immediately goes back to suspend.

VinzNL avatar Jul 13 '24 22:07 VinzNL

What about using hypridle as a systemd-service, and stopping it before suspend and starting it after suspend?

HarshNarayanJha avatar Jul 14 '24 02:07 HarshNarayanJha

I've found an actual workaround for the moment. I'd much rather have it all handled solely through hypridle, but this works for now. If you remove the suspend block from hypridle and use /etc/systemd/logind.conf to control your suspending, then the system actually realizes that it was put to sleep and the timer won't trigger again on wake.

In my case, I created /etc/systemd/logind.conf.d/logind.conf to make sure it survives updates and just put in the following -

[Login]
SleepOperation=suspend
IdleAction=suspend
IdleActionSec=20min

And a standard hypridle config -

general {
    lock_cmd = hyprlock
    before_sleep_cmd = loginctl lock-session
    after_sleep_cmd = hyprctl dispatch dpms on
}

# Screenlock
listener {
    timeout = 600
    on-timeout = loginctl lock-session
}

# Turn off screen
 listener {
     timeout = 630
     on-timeout = hyprctl dispatch dpms off
     on-resume = hyprctl dispatch dpms on
 }

hshl2 avatar Jul 14 '24 17:07 hshl2

came here from a reddit post

im using this restarting hypridle on wake

    general={
        "lock_cmd": ["pidof hyprlock ||  hyprlock"],
        "unlock_cmd": ["pkill -USR1 hyprlock"],
        "before_sleep_cmd": ["loginctl lock-session"],
        "after_sleep_cmd": [
            "(kill $(pidof hypridle) || true) && (pidof hypridle || hypridle)"
        ],
        "ignore_dbus_inhibit": [False],
    },
    listener=[
        # Screenlock
        {
            "timeout": [300],
            "on-timeout": ["loginctl lock-session"],
        },
        # Suspend
        {
            "timeout": [600],
            "on-timeout": ["systemctl suspend"],
        },
    ],

fjueic avatar Jul 15 '24 11:07 fjueic

@fjueic , it looks like the python got cut from the beginning of your code block because it wasn't on the next line after the ```, so if dropped in as is, it will error out with no rules configured. However, taking those components and dropping them into standard hypridle syntax works perfectly and is a much better solution than mine at the moment. Thanks for sharing this.

hshl2 avatar Jul 16 '24 03:07 hshl2

it looks like the python got cut

yes i didn't copy entire file, just wanted to give to an idea

it will error out with no rules configured

i don't use hyprlang to configure hyprwm programs like hyprpaper, hypridle, and hyprland itself. I have a custom library(just one big file) written in python.

So, i just wanted to give a reference as there was no point in sharing the irrelevant python code

fjueic avatar Jul 16 '24 07:07 fjueic

came here from a reddit post

im using this restarting hypridle on wake

    general={
        "lock_cmd": ["pidof hyprlock ||  hyprlock"],
        "unlock_cmd": ["pkill -USR1 hyprlock"],
        "before_sleep_cmd": ["loginctl lock-session"],
        "after_sleep_cmd": [
            "(kill $(pidof hypridle) || true) && (pidof hypridle || hypridle)"
        ],
        "ignore_dbus_inhibit": [False],
    },
    listener=[
        # Screenlock
        {
            "timeout": [300],
            "on-timeout": ["loginctl lock-session"],
        },
        # Suspend
        {
            "timeout": [600],
            "on-timeout": ["systemctl suspend"],
        },
    ],

Hey, regarding this workaround, do we know for sure if, "receiving a dbus post prepare_sleep event" as the wiki puts it, is triggered when the system goes into sleep mode or when it wakes up? I have yet to test it myself, but the wording of the description gives me the impression the command triggers when the system actually goes to sleep rather than when it comes out of sleep.

C-798 avatar Aug 20 '24 17:08 C-798

(kill $(pidof hypridle) || true) && (pidof hypridle || hypridle)

Can't this logic monster be simplified to

killall hypridle; hypridle

alba4k avatar Apr 19 '25 10:04 alba4k

(kill $(pidof hypridle) || true) && (pidof hypridle || hypridle)

Can't this logic monster be simplified to

killall hypridle; hypridle

yes, this is simple. i don't remember why i wrote that. maybe i was just dumb. its works so i never touched it again 🙂

fjueic avatar Apr 19 '25 10:04 fjueic

btw this workaround shouldnt be needed, the idle timer should not be running while the system is asleep lmao

alba4k avatar Apr 19 '25 10:04 alba4k

btw this workaround shouldnt be needed

i tried now and it works fine(maybe fixed). however i would still have that line to be sure

fjueic avatar Apr 19 '25 11:04 fjueic

I found that this prevents any on-resume commands to run after sleep

I will now try with

before_sleep_cmd = touch /tmp/stop-hypridle; ...
after_sleep_cmd = sleep 0.5; rm /tmp/stop-hypridle

listener {
    timeout = 300
    on-timeout = ls /tmp/stop-hypridle || systemctl suspend-then-hibernate
}

alba4k avatar Apr 20 '25 13:04 alba4k