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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1829399 Title: Lid switch triggered suspend takes much longer than UI triggered suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1829399/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
