Suspend on focal takes 30s.

Bug #1980679 reported by b
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
Invalid
Low
Unassigned
xfce4-power-manager (Ubuntu)
New
Undecided
Unassigned

Bug Description

Just upgrades my NUC from Bionic to Focal and suspend went from immediate (within a couple seconds) to taking a whole 30 seconds. While suspend is happening, the machine is still usable, mouse moves, applications respond, all the way until the machine actually goes to sleep. I don't see anything strange in kern.log that would explain the slowness:

Jul 4 08:44:55 domi kernel: [342379.045479] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
Jul 4 08:44:55 domi kernel: [342379.048878] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
Jul 4 08:44:55 domi kernel: [342379.049670] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
Jul 4 08:44:56 domi kernel: [342379.966129] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
Jul 4 08:44:56 domi kernel: [342379.971410] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
Jul 4 08:45:27 domi kernel: [342410.725869] PM: suspend entry (s2idle)
Jul 4 08:45:32 domi kernel: [342410.749912] Filesystems sync: 0.024 seconds
Jul 4 08:45:32 domi kernel: [342410.751470] Freezing user space processes ... (elapsed 0.002 seconds) done.
Jul 4 08:45:32 domi kernel: [342410.753907] OOM killer disabled.
Jul 4 08:45:32 domi kernel: [342410.753907] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Jul 4 08:45:32 domi kernel: [342410.755259] printk: Suspending console(s) (use no_console_suspend to debug)
Jul 4 08:45:32 domi kernel: [342410.755948] e1000e: EEE TX LPI TIMER: 00000011
Jul 4 08:45:32 domi kernel: [342410.812587] sd 2:0:0:0: [sdb] Synchronizing SCSI cache
Jul 4 08:45:32 domi kernel: [342410.812607] sd 1:0:0:0: [sda] Synchronizing SCSI cache
Jul 4 08:45:32 domi kernel: [342410.812708] sd 2:0:0:0: [sdb] Stopping disk
Jul 4 08:45:32 domi kernel: [342410.816870] sd 1:0:0:0: [sda] Stopping disk
Jul 4 08:45:32 domi kernel: [342411.080056] ACPI: EC: interrupt blocked
Jul 4 08:45:32 domi kernel: [342415.597918] ACPI: EC: interrupt unblocked

There does look to be 30s between the last "Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7" and "PM: suspend entry (s2idle)"

This is mostly a frustration, but could be a security issue for some if they suspend the machine and walk away thinking it would be locked but is usable for another 30s.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.4.0-121-generic 5.4.0-121.137
ProcVersionSignature: Ubuntu 5.4.0-121.137-generic 5.4.189
Uname: Linux 5.4.0-121-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.24
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: bbogart 1033 F.... pulseaudio
CasperMD5CheckResult: skip
CurrentDesktop: XFCE
Date: Mon Jul 4 08:43:09 2022
InstallationDate: Installed on 2019-02-09 (1241 days ago)
InstallationMedia: Xubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725)
MachineType: Intel(R) Client Systems NUC8i3BEH
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-121-generic root=UUID=9c982b36-8142-4719-810a-e06f81cab223 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-5.4.0-121-generic N/A
 linux-backports-modules-5.4.0-121-generic N/A
 linux-firmware 1.187.31
SourcePackage: linux
UpgradeStatus: Upgraded to focal on 2022-06-30 (4 days ago)
dmi.bios.date: 10/15/2018
dmi.bios.vendor: Intel Corp.
dmi.bios.version: BECFL357.86A.0051.2018.1015.1513
dmi.board.name: NUC8BEB
dmi.board.vendor: Intel Corporation
dmi.board.version: J72693-304
dmi.chassis.type: 3
dmi.chassis.vendor: Intel Corporation
dmi.chassis.version: 2.0
dmi.modalias: dmi:bvnIntelCorp.:bvrBECFL357.86A.0051.2018.1015.1513:bd10/15/2018:svnIntel(R)ClientSystems:pnNUC8i3BEH:pvrJ72753-303:rvnIntelCorporation:rnNUC8BEB:rvrJ72693-304:cvnIntelCorporation:ct3:cvr2.0:
dmi.product.family: Intel NUC
dmi.product.name: NUC8i3BEH
dmi.product.sku: BOXNUC8i3BEH
dmi.product.version: J72753-303
dmi.sys.vendor: Intel(R) Client Systems

Revision history for this message
b (ben-ekran) wrote :
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Doesn't seem to be a kernel issue.

affects: linux (Ubuntu) → systemd (Ubuntu)
Revision history for this message
Nick Rosbrook (enr0n) wrote :

Is this still an issue? If so, what does the output of systemd-inhibit show? Please also attach logs from journalctl from the time between suspend is initiated, to the time it actually takes place. Finally, if you have any changes to logind's config, that would be good to know:

$ systemd-analyze cat-config systemd/logind.conf

Changed in systemd (Ubuntu):
status: Confirmed → Incomplete
importance: Undecided → Low
Revision history for this message
b (ben-ekran) wrote :

Yes, there is still a delay of 32s between pressing "suspend" and the machine actually going into suspend. See attached systemd-analyze output.

Revision history for this message
Nick Rosbrook (enr0n) wrote :

Can you also share the output of:

$ systemd-inhibit

Based on the your logind.conf attachment, unattended-upgrades increases InhibitDelayMaxSec to 30s. I'm guessing there is an inhibitor that's in place at suspend that is not being released until that max kicks in and suspend continues.

Revision history for this message
b (ben-ekran) wrote :

Related?

# /usr/lib/systemd/logind.conf.d/unattended-upgrades-logind-maxdelay.conf
[Login]
# delay
InhibitDelayMaxSec=30

Revision history for this message
b (ben-ekran) wrote :
Revision history for this message
Nick Rosbrook (enr0n) wrote (last edit ):

> Related?

Yes, that is what I suggest above.

(EDIT: I don't think my first comment was accurate)

I think the problem is probably this combination:

xfce4-power-manager 1000 bbogart 1309 xfce4-power-man handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch xfce4-power-manager handles these events block
xfce4-screensaver 1000 bbogart 1150 xfce4-screensav sleep Locking screen before sleep delay

That installs an inhibitor that blocks the action of handle-suspend-key and others so that xfce4-power-manager can handle it, and then there is also a delay fir xfce4-screensaver to lock before sleep. Based on your original description, it sounds like this lock is not happening, and therefor the inhibitor is not released before the InhibitDelayMaxSec timeout.

In any case, I think systemd is working correctly here, and those inhibitors need to be sorted.

Changed in systemd (Ubuntu):
status: Incomplete → Invalid
Revision history for this message
b (ben-ekran) wrote :

This issue disappeared after installing linux-generic-hwe-20.04 due to another bug.

Revision history for this message
b (ben-ekran) wrote :

It got fixed even before I rebooted; so installing that package changed config files, and indeed I see this:

# /usr/lib/systemd/logind.conf.d/unattended-upgrades-logind-maxdelay.conf
[Login]
# delay
InhibitDelayMaxSec=2

Not sure why it was set to 30s...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.