Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

scheduled wakeup configured, even if autosuspend is disabled in systemd #625

Closed
foxharp opened this issue Feb 20, 2025 · 5 comments
Closed

Comments

@foxharp
Copy link

foxharp commented Feb 20, 2025

I suppose it's possible that this behavior is desired, but it surprised me: I had disabled autosuspend ("systemctl stop autosuspend; systemctl disable autosuspend") in order to work on another suspend/resume program, and was surprised to find (weeks later) that the RTC was still set to the wakeup time configured in autosuspend. The logs contain this, so I guess a pre-suspend hook is still active:

`Feb 20 15:15:35 clover kernel: [ 2479.097790] PM: suspend entry (deep)
Feb 20 15:15:35 clover autosuspend[5600]: 2025-02-20 15:15:35,169 - autosuspend

  • INFO - Configuring check Command with class Command from module autosuspend.ch
    ecks.wakeup using config parameters {'enabled': 'true', 'command': '/usr/local/b
    in/latertoday 4:57am'}
    Feb 20 15:15:35 clover autosuspend[5600]: 2025-02-20 15:15:35,170 - autosuspend
  • INFO - Pre-suspend hook starting, trying to acquire lock
    Feb 20 15:15:35 clover autosuspend[5600]: 2025-02-20 15:15:35,179 - autosuspend
  • INFO - Scheduling next wake up at 2025-02-21 09:56:30+00:00
    Feb 20 15:15:35 clover autosuspend[5600]: 2025-02-20 15:15:35,179 - autosuspend
  • INFO - Scheduling wakeup using command: sh -c 'echo 0 > /sys/class/rtc/rtc0/wa
    kealarm && echo 1740131790 > /sys/class/rtc/rtc0/wakealarm'
    `

Again -- if this is expected/desired, that's fine. Just thought I should mention it.

@languitar
Copy link
Owner

The hook is a separate systemd unit which you also have to disable similar to how you had to enable it (cf. https://autosuspend.readthedocs.io/en/v7.1.0/systemd_integration.html). I'd say there's not much I can do if only on of two units gets disabled.

@foxharp
Copy link
Author

foxharp commented Feb 20, 2025

Ah! Thank you. I suspected it was user error, but it never occurred to me there might be a second unit. Sorry for the trouble.

@foxharp foxharp closed this as completed Feb 20, 2025
languitar added a commit that referenced this issue Feb 22, 2025
Declares the autosuspend-detect-suspend.service in the Also section of
the autosuspend systemd unit. That way, the suspend unit is
enabled/disabled together with the main unit and users don't have to
remember activating/deactivating this unit.

Cf.: #625
@languitar
Copy link
Owner

@foxharp I have found a way to automatically handle the second unit so that only autosuspend.service needs to be activated/deactivated. There's an open PR at #629. Do you want to try if that works for you?

@foxharp
Copy link
Author

foxharp commented Feb 22, 2025

Thanks -- that was fast! Honestly, from the fix description (and I assume you've tested it), then I don't think I need to test. But I'm happy to, if you'd like. (I just need to reinstall, and apply the change manually, correct?)

@languitar
Copy link
Owner

You could, for testing purposes, manually edit the installed systemd unit or use overrides. But I'm fine with just merging this.

renovate-releases bot pushed a commit that referenced this issue Feb 23, 2025
# [7.2.0](v7.1.0...v7.2.0) (2025-02-23)

### Features

* **systemd:** automatically enable/disable suspend hook ([772797a](772797a)), closes [#625](#625)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants