Can't suspend: system resumes for unknown reason after ~40 minutes of sleep
I've bought new MSI Summit B15 which was supplied without OS and happily installed on it fresh Ubuntu 21.04. So far everything works pretty well (except couple of troubles with touchpad & no drivers for FP scanner but that's a different story) except one pretty annoying issue: when I try to suspend the machine it suddenly wakes up in about ~40-60 minutes and start running fans full-speed. Not only it sometimes wakes up me if I happened to sleep nearby, it drains the battery over night, making suspend essentially useless.
I've tried to disable everything (see here how) but power button in /proc/acpi/wakeup, so it looks like this currently:
➜ ~ cat /proc/acpi/wakeup | grep enabled
PWRB S4 *enabled platform:PNP0C0C:00
It doesn't help.
Here is part of syslog (here I've put system to suspend at 7:48 and it started fanning at 8:35 but I logged in later, only at 10:56):
Sep 5 07:48:00 rb-base tracker-store[6784]: OK
Sep 5 07:48:00 rb-base systemd[3246]: tracker-store.service: Succeeded.
Sep 5 07:48:01 rb-base kernel: [ 146.937861] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
Sep 5 07:48:05 rb-base kernel: [ 150.972633] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
Sep 5 07:48:05 rb-base kernel: [ 150.977982] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
Sep 5 07:48:05 rb-base ModemManager[2119]: <info> [sleep-monitor] system is about to suspend
Sep 5 07:48:05 rb-base kernel: [ 150.997219] wlo1: deauthenticating from b0:4e:26:31:82:b8 by local choice (Reason: 3=DEAUTH_LEAVING)
Sep 5 07:48:05 rb-base wpa_supplicant[1978]: wlo1: CTRL-EVENT-DISCONNECTED bssid=b0:4e:26:31:82:b8 reason=3 locally_generated=1
Sep 5 07:48:05 rb-base NetworkManager[1931]: <info> [1630817285.6861] device (wlo1): state change: deactivating -> disconnected (reason 'sleeping', sys-ifac
e-state: 'managed')
Sep 5 07:48:05 rb-base wpa_supplicant[1978]: wlo1: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=0 noise=9999 txrate=0
Sep 5 07:48:07 rb-base systemd[1]: Reached target Sleep.
Sep 5 07:48:07 rb-base systemd[1]: Starting Suspend...
Sep 5 07:48:07 rb-base kernel: [ 152.341436] PM: suspend entry (s2idle)
Sep 5 07:48:07 rb-base systemd-sleep[7072]: Suspending system...
Sep 5 07:48:07 rb-base systemd[1]: zsysd.service: Succeeded.
Sep 5 07:48:07 rb-base kernel: [ 152.424613] Filesystems sync: 0.083 seconds
Sep 5 10:56:42 rb-base kernel: [ 152.426323] Freezing user space processes ... (elapsed 0.002 seconds) done.
Sep 5 10:56:42 rb-base kernel: [ 152.428515] OOM killer disabled.
Sep 5 10:56:42 rb-base kernel: [ 152.428516] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Sep 5 10:56:42 rb-base kernel: [ 152.429676] printk: Suspending console(s) (use no_console_suspend to debug)
Sep 5 10:56:42 rb-base kernel: [ 153.214718] ACPI: EC: interrupt blocked
Sep 5 10:56:42 rb-base kernel: [11468.660690] ACPI: EC: interrupt unblocked
Sep 5 10:56:42 rb-base kernel: [11469.338032] nvme nvme0: 8/0/0 default/read/poll queues
Sep 5 10:56:42 rb-base kernel: [11469.574414] OOM killer enabled.
Sep 5 10:56:42 rb-base kernel: [11469.574416] Restarting tasks ... done.
Sep 5 10:56:42 rb-base kernel: [11469.584884] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
Sep 5 10:56:42 rb-base kernel: [11469.586402] thermal thermal_zone6: failed to read out thermal zone (-61)
Sep 5 10:56:42 rb-base systemd[1]: Condition check resulted in Run anacron jobs being skipped.
Sep 5 10:56:43 rb-base systemd-sleep[7072]: System resumed.
Sep 5 10:56:43 rb-base kernel: [11469.846714] PM: suspend exit
Sep 5 10:56:43 rb-base systemd[1]: systemd-suspend.service: Succeeded.
Sep 5 10:56:43 rb-base systemd[1]: Finished Suspend.
Sep 5 10:56:43 rb-base systemd[1]: Stopped target Sleep.
Sep 5 10:56:43 rb-base systemd[1]: Reached target Suspend.
Sep 5 10:56:43 rb-base systemd[1]: Stopped target Suspend.
Sep 5 10:56:43 rb-base NetworkManager[1931]: <info> [1630828603.2303] manager: sleep: wake requested (sleeping: yes enabled: yes)
Sep 5 10:56:43 rb-base ModemManager[2119]: <info> [sleep-monitor] system is resuming
Sep 5 10:56:43 rb-base NetworkManager[1931]: <warn> [1630828603.5154] sup-iface[499bce01c63427b3,1,wlo1]: call-p2p-cancel: failed with P2P cancel failed
Sep 5 10:56:45 rb-base ModemManager[2119]: <info> [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:14.3': not supported by any plugin
Sep 5 10:56:46 rb-base dbus-daemon[1927]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service' requested by ':1.90' (uid=1000 pid=3490 comm="/usr/bin/gnome-shell " label="unconfined")
Sep 5 10:56:46 rb-base systemd[1]: Starting Fingerprint Authentication Daemon...
Sep 5 10:56:46 rb-base dbus-daemon[1927]: [system] Successfully activated service 'net.reactivated.Fprint'
Sep 5 10:56:46 rb-base systemd[1]: Started Fingerprint Authentication Daemon.
(Here is the full log, in case I've removed something relevant)
As you can see, there's no record at the moment the machine is actually woke up. So my next assumption is that something outside the OS causes wake-up. But system looks not suspended: e.g. monitor is lite up and login screen is shown when immediately when I open the lid, it usually takes some time to start login screen, when I open lid on sleeping system.
UPD1: Thanks to @David comment, although WOL itself is not relevant to my system (MSI Summit doesn't even have an Ethernet card), I've figured out, that I have to search for some configuration in BIOS setup. And I found there "Wake on Thunderbolt™ device" entry which was enabled. I have 0 Thunderbolt™ devices but disabled the entry, just in case. This didn't help though.
UPD2: It seams that /proc/acpi/wakeup just doesn't work: as I mentioned earlier, I've disabled everything but power button in it, however, when I open the lid, computer still wakes up.
UPD3 Battery state dumping script, as suggested by @sancho.s ReinstateMonicaCellio:
#!/bin/bash
TIME="$(date +'%y-%m-%d %H:%M:%S')"
CAPACITY="$(cat /sys/class/power_supply/BAT1/capacity)"
CURRENT="$(cat /sys/class/power_supply/BAT1/current_now)"
VOLTAGE="$(cat /sys/class/power_supply/BAT1/voltage_now)"
echo "$TIME\t$CAPACITY\t\t\t$CURRENT\t$VOLTAGE" >> /home/rb/bat_dump
I don't know if this is your case, but if your system is configured to sleep when closing the lid, and hibernate after say 40 minutes, fans may start at that time, when hibernating. This wouldn't explain the battery drainage, though. Another related case is when the system is configured to hibernate at a certain battery level. So battery drainage occurs first (I wouldn't know why), and that triggers hibernation. Or, the system might be not suspended at all.
Diagnosing PC state
Check relevant events with
$ journalctl --no-pager | cat -n | grep -A 10 -B 3 systemd-logind
You may identify suspends in lines like
9818455 sep 08 22:25:57 MyServer systemd-logind[1132]: Lid closed.
...
9818624 sep 09 06:43:47 MyServer systemd-logind[1132]: Lid opened.
Or use
$ cat -n /var/log/syslog | grep -A 10 -B 3 systemd-logind
Your syslog appears to show an effective sleeping, but I am not sure.
I have PM: suspend entry (deep) (in a Thinkpad) instead of your PM: suspend entry (s2idle).
See also below.
Diagnosing battery drainage
You could write a script, say dump_bat.sh that dumps the battery state to file, with something like
#!/bin/bash
upower -i /org/freedesktop/UPower/devices/battery_BAT0 > battery_$(date | tr " " "_").txt
You could grep specific parts of the output like percentage, time to empty, updated, and History fragments.
Remember
$ chmod +x dump_bat.sh
Placing a cron job to do this every say 10 minutes will help identifying the pattern of battery drainage, and the notebook state (awake/sleeping). Add
*/10 * * * * <path to dump_bat.sh>
with
$ crontab -e
Avoiding battery drainage
Try disabling WOL with this
$ ethtool -s <device> wol d
Combine with diagnosis above.