You are not logged in.
I was having a problem with the suspend to RAM function of my desktop. The computer doesn't wake up and runs to overdrive until I manually reboot. After further investigation, I solved the problem by enabling via /proc/acpi/wakeup, my disabled nvme drive:
echo PXSX > /proc/acpi/wakeupso I created a systemd service file /etc/systemd/system/wakeup-nvme.service:
[Unit]
Description=Wakeup nvme drives from sleep
Before=sleep.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/bash -c "echo PXSX > /proc/acpi/wakeup"
[Install]
WantedBy=sleep.targetI enable the service and it solves my problem of suspend to RAM.
I discovered however that after every kernel update, the service disables on reboot.
My question is should I run a pacman hook after every kernel update to fix this so it remains enabled? Or is it possible to fix this via the service file?
Last edited by d_fajardo (2022-03-14 20:51:27)
Offline
enabling a service just creates a symlink in /etc/systemd/system/. There's no way a kernel update deletes it unless you have a strange hook somewhere to do it specifically.
Last edited by Scimmia (2022-03-12 13:34:52)
Offline
The actual symlink resides in /etc/systemd/system/sleep.target.wants and not in /etc/systemd/system since the actual service file resides there. But I would'nt think this directory situation has any bearing to the problem? I don't see any hook that might disrupt.
Offline
Does the symlink actually get removed w/ kernel updates??
Online
Does the symlink actually get removed w/ kernel updates??
That I failed to check and I've already reenable the service. I'll monitor it then till the next upgrade.
Offline
Does the symlink actually get removed w/ kernel updates??
I revised the title of my post because now I discovered update to systemd disables the service as well.
After the latest systemd upgrade, I rebooted and the drive is back to being disabled at /proc/acpi/wakeup. Checked systemctl status and the service is inactive.
However, the symlink in /etc/systemd/system/sleep.target.wants doesn't get removed.
Still not clear why the service gets disabled on certain updates and yet the symlink exists.
Offline
The service is not going to be active after a reboot until sleep.target is activated by suspend. Inactive doesn't mean disabled.
Offline
Maybe we start this from the other side: what makes you believe the service is disabled?
Online
Maybe we start this from the other side: what makes you believe the service is disabled?
After the said upgrades, kernel or systemd, I reboot and then I check systemctl status wakeup-nvme.service and the service is not loaded but flags that the service does exist.
I also then check /proc/acpi/wakeup, the device meaning to be enabled is back to being disabled.
It surprises me why this is as the symlink continues to exists.
I tried implementing the wakeup call via udev with udev rule but somehow I can't manage to enable the wakeup via this rule. But that could also have been my rule was not good enough.
Offline
I reboot and then I check systemctl status wakeup-nvme.service and the service is not loaded
The service is not going to be active after a reboot until sleep.target is activated by suspend. Inactive doesn't mean disabled.
I also then check /proc/acpi/wakeup, the device meaning to be enabled is back to being disabled.
Because procfs is a transient - it doesn't survive a reboot.
Online
Because procfs is a transient - it doesn't survive a reboot.
Yes of course! That answers it.
What would be the best way to solve this in such a way that I can forget about it?
I'm just thinking of creating a startup script that starts the service on every boot instead of just simply enabling it.
EDIT: It does survive the reboot as long as it's not after a system update. I assume the kernel or systemd resets the procfs on update.
Last edited by d_fajardo (2022-03-14 08:23:54)
Offline
The service is not going to be active after a reboot until sleep.target is activated by suspend. Inactive doesn't mean disabled.
Online
It is seeming more to me that a service file is not the best way to resolve this issue because what I really need is simply to run:
echo PXSX > /proc/acpi/wakeupon boot.
I'll see if I can make it work with a script inside /etc/profile.d.
Last edited by d_fajardo (2022-03-14 10:06:41)
Offline
I'm not sure why you think that's required, but to re-iterate: your current service will only be executed when/right before you send the system to sleep.
If you want to execute it unconditionally, you'd have to move it to eg. the multi-user.target
Online
Great!! Thanks for explaining. Fixed.
Offline
Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.
Edit: blast.
Last edited by seth (2022-03-14 20:51:48)
Online