Thanks Chris, looking at journalct it seems that from the "Lid closed" event and "Reached target Sleep" there's just 1s. So, the time between these two events is also definitely fast, therefore the bottleneck is not in the part of systemd that processes the "lid closed" event.
At this point I'm wondering if the bottleneck is in the part of systemd that detects the "lid closed" event. For that we should run the same loop in a bash session (while :; do echo `date` - `cat /proc/acpi/button/lid/LID0/state`; sleep 1; done), close the lid and compare the timestamps of the transition between "open" and "closed" (in the bash session) with the timestamp of the "Lid closed" event in journalctl. If they don't match the bottleneck is in systemd not being able to detect the lid closed event fast enough. Moreover, in the last comment (#10) you mentioned that things have been improved. Do you have some numbers (i.e., how many second it needs to actually go to sleep) or is it just a feeling? Thanks! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1829399 Title: Lid switch triggered suspend takes much longer than UI triggered suspend Status in linux package in Ubuntu: Incomplete Bug description: IBM T460 5.0.0-13-generic #14-Ubuntu SMP Mon Apr 15 14:59:14 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux When triggering a suspend even from the lid switch of my Lenovo T460 it takes 30 seconds to reach suspend state. Several others with different models of Lenovo laptops have also reproduced this issue. It seems this is isolated to the lid switch as UI triggered suspend (alt+power icon) is far faster. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1829399/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
