Lightdm ignores power saving settings; suspends system in 20 minutes regardless of sleep-inactive-ac-timeout parameter

[Ruben Iskandaryan]

Dear colleagues,

We have discovered an abnormal operation of the lightdm (1.30.0-0ubuntu4~20.04.1) program.

1. When no user is logged in (the initial user selection screen is displayed) the idle system goes into suspend (sleep) mode. The timeout for this event is 20 minutes.

2. I tried to cancel the entering into sleep mode. To do this, I altered the sleep-inactive-ac-timeout and sleep-inactive-battery-timeout parameters to 0.

The command sudo -H -u lightdm dbus-launch --exit-with-session gsettings list-recursively org.gnome.settings-daemon.plugins.power gives the output:

root@supercat:/home/supercat# sudo -H -u lightdm dbus-launch --exit-with-session gsettings list-recursively org.gnome.settings-daemon.plugins.power
No protocol specified
org.gnome.settings-daemon.plugins.power lid-close-ac-action 'suspend'
org.gnome.settings-daemon.plugins.power time-critical 300
org.gnome.settings-daemon.plugins.power power-button-action 'suspend'
org.gnome.settings-daemon.plugins.power lid-close-suspend-with-external-monitor false
org.gnome.settings-daemon.plugins.power button-hibernate 'hibernate'
org.gnome.settings-daemon.plugins.power idle-dim true
org.gnome.settings-daemon.plugins.power button-power 'suspend'
org.gnome.settings-daemon.plugins.power lid-close-battery-action 'suspend'
org.gnome.settings-daemon.plugins.power priority 0
org.gnome.settings-daemon.plugins.power idle-brightness 30
org.gnome.settings-daemon.plugins.power active true
org.gnome.settings-daemon.plugins.power critical-battery-action 'hibernate'
org.gnome.settings-daemon.plugins.power button-suspend 'suspend'
org.gnome.settings-daemon.plugins.power button-sleep 'hibernate'
org.gnome.settings-daemon.plugins.power percentage-critical 3
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'suspend'
org.gnome.settings-daemon.plugins.power ambient-enabled true
org.gnome.settings-daemon.plugins.power notify-perhaps-recall true
org.gnome.settings-daemon.plugins.power percentage-low 10
org.gnome.settings-daemon.plugins.power percentage-action 2
org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type 'suspend'
org.gnome.settings-daemon.plugins.power time-low 1200
org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 0
org.gnome.settings-daemon.plugins.power time-action 120
org.gnome.settings-daemon.plugins.power use-time-for-policy true

3. I checked the result, the system still suspends (goes into sleep mode) in 20 minutes. I checked the IdleAction parameter in /etc/systemd/logind.conf, because it may affect the suspend mode. It is set to ignore.

# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See logind.conf(5) for details.

[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
#HandleLidSwitch=suspend
#HandleLidSwitchExternalPower=suspend
#HandleLidSwitchDocked=ignore
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#HoldoffTimeoutSec=30s
IdleAction=ignore
IdleActionSec=30min
#RuntimeDirectorySize=10%
#RemoveIPC=yes
#InhibitorsMax=8192
#SessionsMax=8192

I came to conclusion that lightdm ignores correctly given setting for not suspending the system (org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0).

Commentaries on this finding are welcome.
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu27.17
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: GNOME
DistroRelease: Ubuntu 20.04
Package: lightdm 1.30.0-0ubuntu4~20.04.1
PackageArchitecture: amd64
Tags: focal third-party-packages
Uname: Linux 5.4.96-050496-lowlatency x86_64
UpgradeStatus: Upgraded to focal on 2021-02-10 (92 days ago)
UserGroups: android audio cdrom dialout dip fax floppy fuse lpadmin netdev plugdev sambashare scanner tape users vboxusers video
_MarkForUpload: True
modified.conffile..etc.default.apport:
 # set this to 0 to disable apport, or to 1 to enable it
 # you can temporarily override this with
 # sudo service apport start force_start=1
 enabled=0
mtime.conffile..etc.default.apport: 2014-03-07T13:05:12.906701

[Chris Guiver (guiverc)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command only once, as it will automatically gather debugging information, in a terminal:

apport-collect 1928305

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

[Ruben Iskandaryan (kot-2)]

apport information

[Ruben Iskandaryan (kot-2)]

apport information

[Ruben Iskandaryan (kot-2)]

apport information

[Ruben Iskandaryan (kot-2)]

apport information

[Ruben Iskandaryan (kot-2)]

apport information

[Ruben Iskandaryan (kot-2)]

apport information

[Ruben Iskandaryan (kot-2)]

apport information

[Ruben Iskandaryan (kot-2)]

apport information

[Ruben Iskandaryan (kot-2)]

While I waited for reply, I found an appropriate solution.
The cause of the problem was that in the system with lightdm and unity-greeter
installed as a desktop manager and a greeter respectively timeout intervals are
given _twice_ as numeric values:

(1) Time before suspend in lightdm.
(2) Time before suspend in unity-greeter.

To change the first set of parameters (for lightdm) I needed to specify the values for
the user lightdm by means of dconf editor:

sudo -u lightdm dbus-launch gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0
sudo -u lightdm dbus-launch gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 0

I also changed the type of action after the suspend time elapses to 'nothing'

sudo -u lightdm dbus-launch gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
sudo -u lightdm dbus-launch gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type 'nothing'

To change the second set of parameters (for unity-greeter) I needed to perform a
similar action:

sudo -u lightdm dbus-launch gsettings set com.canonical.unity.settings-daemon.plugins.power sleep-inactive-ac-timeout 0
sudo -u lightdm dbus-launch gsettings set com.canonical.unity.settings-daemon.plugins.power sleep-inactive-battery-timeout 0

And

sudo -u lightdm dbus-launch gsettings set com.canonical.unity.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
sudo -u lightdm dbus-launch gsettings set com.canonical.unity.settings-daemon.plugins.power sleep-inactive-battery-type 'nothing'

Test showed that no further suspend event was observed.

There was no bug, rather simple misunderstanding of that lightdm and unity-greeter store parameters in different places.

With kind regards, Ruben Alexandrovich Iskandaryan.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[amk (9-launchpad-mikus-sk)]

Lightdm shall never suspend the system itself. Instead it should properly report idle status to systemd where a decision can be taken by checking all relevant services, sessions and inhibitors.

In the past I have reported that idle suspend does not work while showing login screen:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1730606

After upgrade to 20.4 the system keeps suspending when one seat is showing login screen despite of a user is typing on another seat.

The workaround here seems to help with the unwanted suspend, and still needs the cron job to override the missing idle hint and to suspend when applicable.

Another similar reports mentioning multiseat setup as a victim of the gdm not playing in the team with systemd: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/22