Hello experts,
my computer has a weird behaviour: if I put it in suspended mode, sometimes it does, sometimes it wakes up back again, either immediately or after 4~5 seconds. After 3 or 4 attempts, it gets in suspended mode permanently.
Is there a way to trace down what device/event triggered the wake? I would try to disable the culprit via an udev rule, if I figured out which one it is.
Hi @LordDaveTheKind,
You can check your logs regarding the systemd-suspend.service with:
journalctl --unit systemd-suspend.service
If you wish to post it here, it might be better to upload it to pastebin or the like and provide the link here.
Worth noting that the Lenovo Iām currently using wonāt stay in suspend (wakes back up straight away) unless I unplug the wired USB mouse immediately after clicking the suspend option.
Same issue with one of the keyboards; an old PS/2 model connected via an adaptor. You can leave the USB part plugged in, as long as you disconnect the keyboardās own plug. Thatās a shame as that KB and its identical twin have power and media controls.
Iāll follow this with interest! 
You can see what can devices/buses can wake up your system with:
sudo cat /proc/acpi/wakeup
And after the system wakes up, get the stats with:
sudo cat /sys/kernel/debug/wakeup_sources
This can be a lot to readā¦
But the devices that have numbers for things like total_time, I was able to track down the PCIe ID of the USB controller with the keyboard plugged into it.
I am not sure if we can get more narrow than that?
Another thing that could potentially wake up your system is a systemd timer.
systemctl list-timers --all
You could try:
systemctl suspend -i
man systemctl:
-i Shortcut for --check-inhibitors=no.
Just tested on my system. It works ā¦ as long as the mouse isnāt moved, because that triggers a wake event (which doesnāt happen if the mouse is unplugged and then re-connected later, before waking (via key press)).
My workaround: the mouse can āsleepā on its back when I go out. 
Something that might be worth checking out:
Check that your UEFI isnāt set to wake-up from suspend on mouse movement. I know mine has a setting for that, so that might play a role.
@LordDaveTheKind, this might be something for you to double-check as well.
The wake on lan could be another culprit, as you mentioned the phantom wake movements from mouse (boy i once had a tiny hair in the laser, it drove me crazy till i found it, pc waked up, the pointer jumped but only sometimes).
I had a NAS on my home network once, which had the habit of broadcasting wake on lan to all because it wanted to contact some proprietary software on the pc from time to time.
I have already disabled mouse and keyboard via a dedicated udev rule and tested them, but the issue is still there. Iām proceeding with the other tracing methods mentioned in the thread.
Here is the log concerning a specific suspend process:
ā Boot 97549f54c4944a0988d53433605a20a0 ā
Apr 21 17:15:08 towerpc systemd[1]: Starting System Suspendā¦
Apr 21 17:15:08 towerpc systemd-sleep[12307]: User sessions remain unfrozen on explicit request ($SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0).
Apr 21 17:15:08 towerpc systemd-sleep[12307]: This is not recommended, and might result in unexpected behavior, particularly
Apr 21 17:15:08 towerpc systemd-sleep[12307]: in suspend-then-hibernate operations or setups with encrypted home directories.
Apr 21 17:15:08 towerpc systemd-sleep[12307]: Performing sleep operation āsuspendāā¦
Apr 21 17:15:16 towerpc systemd-sleep[12307]: System returned from sleep operation āsuspendā.
Apr 21 17:15:16 towerpc systemd[1]: systemd-suspend.service: Deactivated successfully.
Apr 21 17:15:16 towerpc systemd[1]: Finished System Suspend.
I also tried to set the value of Env. Variable SYSTEMD_SLEEP_FREEZE_USER_SESSIONS as 1 in the conf file /etc/environment and rebooted, but with no different result.
I recorded the content for file wakeup_sources before and after the suspend, for both a success (ok) and an experienced issue (ko):
I tried to check the differences for both the ok and the ko cases, but I wasnāt able to find any relevant difference in the tracked sources:
$ diff wakeup_sources-ko-before.txt wakeup_sources-ko-after.txt
4c4
< 13-3 5 5 0 0 0 0 0 717963 0
---
> 13-3 6 6 0 0 0 0 0 1789769 0
24,25c24,25
< PNP0C0C:00 7 7 0 0 0 0 0 717904 0
< LNXPWRBN:00 4 4 0 0 0 0 0 670226 0
---
> PNP0C0C:00 8 8 0 0 0 0 0 1789712 0
> LNXPWRBN:00 5 5 0 0 0 0 0 1786851 0
$ diff wakeup_sources-ok-before.txt wakeup_sources-ok-after.txt
4c4
< 13-3 2 2 0 0 0 0 0 476233 0
---
> 13-3 3 3 0 0 0 0 0 563592 0
24,25c24,25
< PNP0C0C:00 2 2 0 0 0 0 0 476175 0
< LNXPWRBN:00 0 0 0 0 0 0 0 0 0
---
> PNP0C0C:00 3 3 0 0 0 0 0 563533 0
> LNXPWRBN:00 1 1 0 0 0 0 0 561255 0
This is awesome, itās often what I do to other peoplesā outputs. 
Unfortunately, this is not giving us the information I was hoping for. Like wakeup_count, but I donāt think this is completely useless..
ACPI is not my forte, but I can usually fumble around enough to figure it out.
Hopefully this is not a red herring, but we can see activity around:
13-3 - USB device: 013:003PNP0C0C:00 - ACPI hardware ID (for your motherboard)LNXPWRBN:00 - Linux power button (interface/API)What was the rule?
In troubleshooting this, I would probably trying non-persistent changes to see what works first.
e.g. Letās blame Plug and Play C0C:00!
echo "disabled" | sudo tee /sys/bus/acpi/devices/PNP0C0C:00/power/wakeup
Then test them one at a time..
Thank you for this feedback! It has been very helpful.
USB Device at 013:003 is a Bluetooth adapter, which I use for turning my computer on with a PlayStation DualSense. And unfortunately seems to be the responsible also for the unsolicited wakeups.
Could it be a hardware issue, maybe a Bluetooth interference?
Hardware issue, Iām sure it works as expected.
Interference, unlikely. Especially if it works at all.
Software issue, the drivers aka kernel modules, or basically Linux software support for this bluetooth device?
- Iād say most likely?
I would disable the wake function for the controller myself.
Does this fix it for you?
echo disabled | sudo tee /sys/bus/usb/devices/13-3/power/wakeup
If that works, then you can create a persistent udev rule.
rebootor run the command again withecho enabled | sudo tee ...
Then it is simply creating a file, such as:
/etc/udev/rules.d/99-disable-ps-wake.rules
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="aaaa", ATTR{idProduct}=="bbbb", TEST=="power/wakeup", ATTR{power/wakeup}="disabled"With your proper
ATTR{idVendor}andATTR{idProduct}.
Reload rules and apply them:
sudo udevadm control --reload
sudo udevadm trigger
Yes in the end Iāll sort it out like this. Itās not a solution, as Iād loose a desired functionality, but apparently the new Steam Controller is off soon, and I can dismiss to do it via Bluetooth.
Thanks everyone who collaborated to the thread. I will close it now.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.