Bug#919694: elogind triggers ACPI suspend on laptop lid close, contrary to prior acpi-support configuration

[Zygo Blaxell]

On Fri, Jan 18, 2019 at 09:27:27PM +0000, Mark Hindley wrote:
> 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?

It seems to.

Given that elogind conflicts with and functionally replaces pieces of
systemd, wouldn't it make sense for them to use the same config file?

I proactively install systemd configuration fragments on systems running
sysvinit to avoid cases precisely like this one, where some piece of
systemd gets split off and suddenly appears on a sysvinit system during
an apt-get.  Had elogind read the systemd-logind config file instead of
its own, this could have been avoided (or at least resolved sooner by
replaying a previously documented solution).

> > 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.

That seems unfortunate as the two packages are not exact functional
replacements of each other, but it would solve this particular problem.

I'd expect systemd and acpi-support to conflict for the same reason,
but they don't.  Maybe the problem is solved there in a different way?
Or maybe installing systemd on a machine with previously configured
acpi-support has the same bug.

> Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/attachments/20190118/51c85cff/attachment.sig>