Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Wow, thanks for this tip! I've been dealing with suspend issues with an X570 Aorus Master as well.

Running `echo GPP0 >> /proc/acpi/wakeup` into a systemd unit at boot solved the issue for me... except the first sleep after a boot would always wake back up immediately.

I applied your udev rule and that issue seems to be resolved as well!



This is more so for your future unit file use: did you use `Type=oneshot` and `RemainAfterExit=yes`?

I remember there being some strange interaction with the wakeup behaviour being toggled otherwise. But this could be due to me being on NixOS.


I just did `ExecStart` with `multi-user.target`. That implies the unit is `simple`, so it very well could be sequencing incorrectly at boot and failing. That's a good point; I'll have to keep that in mind!


Apologies for the confusion, I don't mean it was failing to run.

If you don't add "RemainAfterExit", the service will run at every boot, because after a reboot it is considered "inactive. This will execute your shell code, which effectively toggles wakeup.

"RemainAfterExit" is meant for unit files that change the state of your system. After running once, the service will be considered "active", until you manually deactivate it, which will execute whatever you might have set in "ExecStop".

"Type=Oneshot" is necessary for "RemainAfterExit".

In this case I still would prefer doing it via udev though. I've made it my rule of thumb to evade shell scripting wherever feasible, because it usually ends up being more brittle, and more prone to footgunning :)


Ahh, gotcha, thanks for the tip. Yeah, systemd is easy to reach for, but it certainly has plenty of footguns.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: