Bug#919694: elogind triggers ACPI suspend on laptop lid close, contrary to prior acpi-support configuration
Mark Hindley
mark at hindley.org.uk
Fri Jan 18 21:27:27 GMT 2019
On Fri, Jan 18, 2019 at 03:19:11PM -0500, Zygo Blaxell wrote:
> I get:
[snipped]
> HandleLidSwitch=suspend
> HandleLidSwitchDocked=ignore
> Docked=yes
> It seems there is some significant lag (several seconds, maybe a minute
> or two) before "Docked" changes to the correct value. The "Docked" state
> definitely does not update while the rapid suspends are happening. I can
> wake the laptop with the docked keyboard spacebar, but it immediately
> goes back to sleep again, at least 20 times. After that it starts
> ignoring the spacebar and stays asleep until I undock and open the lid.
>
> I encountered a similar problem on another laptop some months ago, where
> that laptop's lid switch was always reporting closed. That system was
> running systemd, and the fix was to set HandleLidSwitch=ignore, but in
> a different configuration file from what elogind uses.
And does that fix work for elogind too if you set it in /etc/elogind/logind.conf?
> Note that docked state tracking is irrelevant to the original issue
> I was reporting.
Hmmm, the docked state changes which action elogind executes for the lid switch
-- HandleLidSwitch or HandleLidSwitchDocked. The defaults for each are
different. If the Docked state is slow to update then the wrong action might be
being invoked.
I also notice you have
> InhibitDelayMaxUSec=5s
> UserStopDelayUSec=0
> HoldoffTimeoutUSec=30s
> IdleActionUSec=30min
The manpage refers to InhibitDelayMaxSec, UserStopDelaySec, HoldoffTimeoutSec
and IdleActionSec (no 'U'). I will have to look into the significance of those.
> I had configured acpi-support to take no suspend
> action on lid close, docked or otherwise. elogind appears to be
> unaware of acpi-support's overlapping functionality, and the maintainer
> scripts for elogind don't adjust elogind's configuration to disable
> lid/power/hibernate key handling if there's another ACPI event handler
> already installed on the system. Both can be installed at the same time,
> and by default both will try to suspend the system, so in the worst case
> you could get two suspend/resume cycles per lid close (which is a great
> way to find ACPI firmware bugs).
Yes, maybe elogind and acpi-support should just conflict.
Mark
More information about the Debian-init-diversity
mailing list