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

Mark Hindley mark at hindley.org.uk
Sat Jan 19 10:34:02 GMT 2019

Tags: upstream

On Fri, Jan 18, 2019 at 04:58:22PM -0500, Zygo Blaxell wrote:
> > > 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.


One issue I will pass upstream is why the Docked status is taking so long to
update. Once docked elogind should be ignoring lid events by default. (I know
this doesn't address the underlying issue in this case, but it would no longer
be problematic.)
> > > 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.

Yes I agree, but I cannot see a way for elogind to tell if another handler is
also listening to lid events.

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

Unfortunately I don't have any suitable hardware to test that. Are you able to?



More information about the Debian-init-diversity mailing list