On Fri, Jan 18, 2019 at 05:00:19PM +0000, Mark Hindley wrote: > On Fri, Jan 18, 2019 at 11:18:27AM -0500, Zygo Blaxell wrote: > > Source: elogind > > Version: 239.3-4+debian1 > > Severity: important > > > > Dear Maintainer, > > > > I installed elogind on a laptop because it was a dependency of other > > packages. When I attempted to use the laptop in a docking station > > with the lid closed, it immediately and repeatedly went into suspend, > > despite my prior configuration of acpi-support to not take any action > > on lid close. > > Zygo, > > Thanks for this. > > Could you reinstall elogind and post the output of 'loginctl show-seat' when > in > the docking station? I am particularly interested in the values of Docked, > HandleLidSwitch and HandleLidSwitchDocked.
I get:
EnableWallMessages=no
KillUserProcesses=no
RebootToFirmwareSetup=no
IdleHint=yes
IdleSinceHint=0
IdleSinceHintMonotonic=0
InhibitDelayMaxUSec=5s
UserStopDelayUSec=0
HandlePowerKey=poweroff
HandleSuspendKey=suspend
HandleHibernateKey=hibernate
HandleLidSwitch=suspend
HandleLidSwitchDocked=ignore
HoldoffTimeoutUSec=30s
IdleAction=ignore
IdleActionUSec=30min
PreparingForShutdown=no
PreparingForSleep=no
Docked=yes
RemoveIPC=yes
RuntimeDirectorySize=1649360896
InhibitorsMax=8192
NCurrentInhibitors=0
SessionsMax=8192
NCurrentSessions=0
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.
Note that docked state tracking is irrelevant to the original issue
I was reporting. 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).
signature.asc
Description: PGP signature
