Arch Linux

TheCoon

Member

Registered: 2016-05-10

Posts: 42

Suspend/Sleep not working after disabling GDM

I'll give some background info before describing the issue I'm facing.

I made the move to Arch several years ago, and I had been using GNOME as a DE for a couple years since first installation (Lenovo laptop). 

At some point I moved to i3wm, but I didn't remove or uninstall much of what was left over from GNOME. Not only that, but I kept GDM enabled and it served as my login manager, so I would login to i3, and other than that I didn't use any of GNOME's installed utilities.

A short while ago (about one month), I decided to disable the GDM systemd service, and just set my ~/.xinitrc to run startx when I login to tty1. Around this time I wanted to disable any other unneeded GNOME leftovers, and made some changes to my system's configs to adapt to the new GDM-less setup - for example, scripts/services which used to refer to my active desktop as DISPLAY :1 now had to be changed to :0.
Overall I'm very happy with my current setup, but there is still one issue which greatly disturbs me and has been for a couple weeks now. I turn to the forum now for help since I can't seem to solve this issue on my own.
It used to be that I would close the laptop lid and the system would go into sleep/suspend (to clarify, I mean systemctl suspend, AKA suspend to RAM). Then I could open the lid and it would awaken. This worked flawlessly (maybe 99% of the time).

After disabling GDM (I'm not sure if this is exactly the reason, but it was the biggest change I can point to), suspend isn't working consistently. Suspend after lid close may work several times, and then one time it just doesn't.
What happens is that the /usr/lib/systemd-sleep suspend process freezes for some reason, and the system is left in a state where I can't shutdown/reboot/suspend or anything, can't kill the process either.

Here's what I see in the journal:

Nov 25 15:42:58 myhostname systemd[1]: Reached target Sleep.
Nov 25 15:42:58 myhostname systemd[1]: Starting Suspend...
Nov 25 15:42:58 myhostname systemd-sleep[32338]: Suspending system...
Nov 25 15:42:58 myhostname kernel: PM: suspend entry (deep)
Nov 25 15:42:58 myhostname kernel: PM: Syncing filesystems ... done.
Nov 25 15:43:18 myhostname kernel: Freezing user space processes ... (elapsed 0.004 seconds) done.
Nov 25 15:43:18 myhostname kernel: OOM killer disabled.
Nov 25 15:43:18 myhostname kernel: Freezing remaining freezable tasks ... 
Nov 25 15:43:18 myhostname kernel: Freezing of tasks failed after 20.005 seconds (0 tasks refusing to freeze, wq_busy=1):
Nov 25 15:43:18 myhostname kernel: Showing busy workqueues and worker pools:
Nov 25 15:43:18 myhostname kernel: workqueue events_freezable: flags=0x4
Nov 25 15:43:18 myhostname kernel:   pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/0
Nov 25 15:43:18 myhostname kernel:     in-flight: 11717:thermal_zone_device_check BAR(11717)
Nov 25 15:43:18 myhostname kernel: workqueue events_freezable_power_: flags=0x86
Nov 25 15:43:18 myhostname kernel:   pwq 16: cpus=0-7 flags=0x4 nice=0 active=0/0
Nov 25 15:43:18 myhostname kernel:     delayed: disk_events_workfn, disk_events_workfn
Nov 25 15:43:18 myhostname kernel: workqueue writeback: flags=0x4e
Nov 25 15:43:18 myhostname kernel:   pwq 16: cpus=0-7 flags=0x4 nice=0 active=0/0
Nov 25 15:43:18 myhostname kernel:     delayed: wb_workfn
Nov 25 15:43:18 myhostname kernel: pool 0: cpus=0 node=0 flags=0x0 nice=0 hung=0s workers=3 idle: 31371 26129
Nov 25 15:43:18 myhostname kernel: Restarting kernel threads ... done.
Nov 25 15:43:18 myhostname kernel: OOM killer enabled.
Nov 25 15:43:18 myhostname rtkit-daemon[3405]: The canary thread is apparently starving. Taking action.
Nov 25 15:43:18 myhostname rtkit-daemon[3405]: Demoting known real-time threads.
Nov 25 15:43:18 myhostname rtkit-daemon[3405]: Successfully demoted thread 3411 of process 3399.
Nov 25 15:43:18 myhostname rtkit-daemon[3405]: Successfully demoted thread 3410 of process 3399.
Nov 25 15:43:18 myhostname rtkit-daemon[3405]: Successfully demoted thread 3399 of process 3399.
Nov 25 15:43:18 myhostname rtkit-daemon[3405]: Demoted 3 threads.
Nov 25 15:43:18 myhostname kernel: Restarting tasks ... done.
Nov 25 15:47:57 myhostname systemd-logind[713]: Lid opened.
Nov 25 15:47:57 myhostname kernel: acpi device:31: Cannot transition to power state D3hot for parent in (unknown)
Nov 25 15:47:57 myhostname kernel: pci_bus 0000:01: Allocating resources

After searching for ages and trying different solutions, I thought I might have finally found the culprit, and disabled upower, which is GNOME's power manager. This didn't solve the issue.
I'm using the linux-lts kernel, and switching to linux and linux-hardened didn't change anything.
I tried downgrading linux-firmware to versions from up to 6 months ago, and this didn't help either.

Here is my /etc/systemd/logind.conf:

[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
InhibitDelayMaxSec=5
HandleLidSwitch=suspend
HandleLidSwitchDocked=suspend
HandleLidSwitchExternalPower=suspend
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
HoldoffTimeoutSec=15s

Any help with debugging this is greatly appreciated. I really feel stuck, the only option I can think of is reinstalling, but I would really like to avoid that, especially since I just have to know what is causing this issue.

JanErik

Member

Registered: 2018-01-08

Posts: 56

Re: Suspend/Sleep not working after disabling GDM

Suspend is broken after last weeks kernel update, see https://bbs.archlinux.org/viewtopic.php?id=250863 .

TheCoon

Member

Registered: 2016-05-10

Posts: 42

Re: Suspend/Sleep not working after disabling GDM

Suspend is broken after last weeks kernel update, see https://bbs.archlinux.org/viewtopic.php?id=250863 .

Would that also affect 4.19.86-1-lts ?
This has been an issue for me for at least a week, maybe two. The errors in the journal seem different in the thread linked. I'll try downgrading the kernel either way, maybe it is related. Willing to try anything at this point.
EDIT: Downgraded from linux-lts 4.19.86-1 to 4.19.81-1, now I'll just have to wait see.

Last edited by TheCoon (2019-11-29 13:39:11)

Flapper

Member

Registered: 2019-02-10

Posts: 46

Re: Suspend/Sleep not working after disabling GDM

I don't think it does affect the lts.
I posted the issue here with kernel 5.3.12 https://bbs.archlinux.org/viewtopic.php?id=250863, and I have since installed linux-lts 4.19.86-1 and have no problems with suspend.

TheCoon

Member

Registered: 2016-05-10

Posts: 42

Re: Suspend/Sleep not working after disabling GDM

I don't think it does affect the lts.
I posted the issue here with kernel 5.3.12 https://bbs.archlinux.org/viewtopic.php?id=250863, and I have since installed linux-lts 4.19.86-1 and have no problems with suspend.

That's interesting, because ever since I downgraded to 4.19.81-1 I haven't had an issue with suspend. It's been 2-3 days so far, so I'm hopeful it continues working. I'll update here if suspend fails again using this kernel.

EDIT: In case this affects anyone else... A few days after downgrading to 4.19.81-1 the sleep issue happened again. This time I tried downgrading systemd, 243.162-2 to 243.78-2. If suspend keeps working for another week, I will assume systemd was the culprit. After that I will upgrade to the latest release (244 at the moment), and if the issue comes back I will know almost definitely that the issue was introduced somewhere after 243.78-2; if not, it might have already been reported and resolved/rolled back.

Last edited by TheCoon (2019-12-11 09:14:28)

TheCoon

Member

Registered: 2016-05-10

Posts: 42

Re: Suspend/Sleep not working after disabling GDM

Posting again because this issue just won't go away. I'm on the verge of reinstalling the entire system, but maybe someone will be able to help me debug this and possibly avoid a reinstallation.

Sleep failed again using the downgraded systemd and downgraded linux-lts. So I installed the latest versions of both.

Here is the journal right before closing the lid, and right after opening the lid (a suspend is attempted in between, but fails).
How can I debug this? How can I determine the cause of these errors? What's holding the system back?

Dec 11 16:22:04 myhostname systemd-logind[853]: Lid closed.
Dec 11 16:22:04 myhostname kernel: acpi device:31: Cannot transition to power state D3hot for parent in (unknown)
Dec 11 16:22:04 myhostname kernel: pci_bus 0000:01: Allocating resources
Dec 11 16:22:04 myhostname systemd-logind[853]: Suspending...
Dec 11 16:22:04 myhostname NetworkManager[824]: <info>  [1576160524.4118] manager: sleep: sleep requested (sleeping: no  enabled: yes)
Dec 11 16:22:04 myhostname NetworkManager[824]: <info>  [1576160524.4134] device (p2p-dev-wlp1s0): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
Dec 11 16:22:04 myhostname NetworkManager[824]: <info>  [1576160524.4199] manager: NetworkManager state is now ASLEEP
Dec 11 16:22:04 myhostname systemd[1]: Starting Lock screen before suspend...
Dec 11 16:22:05 myhostname wpa_supplicant[832]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-73 noise=9999 txrate=324000
Dec 11 16:22:08 myhostname systemd[1]: Started Lock screen before suspend.
Dec 11 16:22:08 myhostname audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=i3lock comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 11 16:22:08 myhostname kernel: audit: type=1130 audit(1576160528.107:189): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=i3lock comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 11 16:22:08 myhostname systemd[1]: Reached target Sleep.
Dec 11 16:22:08 myhostname systemd[1]: Starting Suspend...
Dec 11 16:22:08 myhostname systemd-sleep[45202]: Suspending system...
Dec 11 16:22:08 myhostname kernel: PM: suspend entry (deep)
Dec 11 16:22:28 myhostname kernel: PM: Syncing filesystems ... done.
Dec 11 16:22:28 myhostname kernel: Freezing user space processes ... (elapsed 0.002 seconds) done.
Dec 11 16:22:28 myhostname kernel: OOM killer disabled.
Dec 11 16:22:28 myhostname kernel: Freezing remaining freezable tasks ... 
Dec 11 16:22:28 myhostname kernel: Freezing of tasks failed after 20.008 seconds (0 tasks refusing to freeze, wq_busy=1):
Dec 11 16:22:28 myhostname kernel: Showing busy workqueues and worker pools:
Dec 11 16:22:28 myhostname kernel: workqueue events_freezable: flags=0x4
Dec 11 16:22:28 myhostname kernel:   pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/0
Dec 11 16:22:28 myhostname kernel:     in-flight: 44676:thermal_zone_device_check BAR(44676)
Dec 11 16:22:28 myhostname kernel: workqueue events_freezable_power_: flags=0x86
Dec 11 16:22:28 myhostname kernel:   pwq 16: cpus=0-7 flags=0x4 nice=0 active=0/0
Dec 11 16:22:28 myhostname kernel:     delayed: disk_events_workfn, disk_events_workfn
Dec 11 16:22:28 myhostname kernel: workqueue writeback: flags=0x4e
Dec 11 16:22:28 myhostname kernel:   pwq 16: cpus=0-7 flags=0x4 nice=0 active=0/0
Dec 11 16:22:28 myhostname kernel:     delayed: wb_workfn, wb_workfn
Dec 11 16:22:28 myhostname kernel: pool 0: cpus=0 node=0 flags=0x0 nice=0 hung=0s workers=4 idle: 42484 44992 43765
Dec 11 16:22:28 myhostname kernel: Restarting kernel threads ... done.
Dec 11 16:22:28 myhostname kernel: OOM killer enabled.
Dec 11 16:22:28 myhostname kernel: Restarting tasks ... done.
Dec 11 16:22:28 myhostname rtkit-daemon[2744]: The canary thread is apparently starving. Taking action.
Dec 11 16:22:28 myhostname wpa_supplicant[832]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-57 noise=9999 txrate=324000
Dec 11 16:22:28 myhostname rtkit-daemon[2744]: Demoting known real-time threads.
Dec 11 16:22:28 myhostname rtkit-daemon[2744]: Successfully demoted thread 2753 of process 2743.
Dec 11 16:22:28 myhostname rtkit-daemon[2744]: Successfully demoted thread 2752 of process 2743.
Dec 11 16:22:28 myhostname rtkit-daemon[2744]: Successfully demoted thread 2743 of process 2743.
Dec 11 16:22:28 myhostname rtkit-daemon[2744]: Demoted 3 threads.
Dec 11 16:22:32 myhostname kernel: INFO: task kworker/0:1:44676 blocked for more than 120 seconds.
Dec 11 16:22:32 myhostname kernel:       Tainted: G           OE     4.19.88-1-lts #1
Dec 11 16:22:32 myhostname kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 11 16:22:32 myhostname kernel: kworker/0:1     D    0 44676      2 0x80000080
Dec 11 16:22:32 myhostname kernel: Workqueue: events_freezable thermal_zone_device_check
Dec 11 16:22:32 myhostname kernel: Call Trace:
Dec 11 16:22:32 myhostname kernel:  ? __schedule+0x27c/0x8c0
Dec 11 16:22:32 myhostname kernel:  schedule+0x32/0x80
Dec 11 16:22:32 myhostname kernel:  schedule_timeout+0x2f4/0x480
Dec 11 16:22:32 myhostname kernel:  wait_for_common+0xf4/0x1b0
Dec 11 16:22:32 myhostname kernel:  ? wake_up_q+0x60/0x60
Dec 11 16:22:32 myhostname kernel:  __flush_work+0x136/0x1f0
Dec 11 16:22:32 myhostname kernel:  ? flush_workqueue_prep_pwqs+0x140/0x140
Dec 11 16:22:32 myhostname kernel:  __cancel_work_timer+0x11b/0x1a0
Dec 11 16:22:32 myhostname kernel:  handle_thermal_trip+0xd1/0x220
Dec 11 16:22:32 myhostname kernel:  thermal_zone_device_update.part.0+0x60/0x190
Dec 11 16:22:32 myhostname kernel:  process_one_work+0x1da/0x3b0
Dec 11 16:22:32 myhostname kernel:  worker_thread+0x4d/0x3f0
Dec 11 16:22:32 myhostname kernel:  kthread+0xfb/0x130
Dec 11 16:22:32 myhostname kernel:  ? process_one_work+0x3b0/0x3b0
Dec 11 16:22:32 myhostname kernel:  ? kthread_park+0x80/0x80
Dec 11 16:22:32 myhostname kernel:  ret_from_fork+0x35/0x40
Dec 11 16:23:13 myhostname systemd-logind[853]: Lid opened.
Dec 11 16:23:13 myhostname kernel: acpi device:31: Cannot transition to power state D3hot for parent in (unknown)
Dec 11 16:23:13 myhostname kernel: pci_bus 0000:01: Allocating resources

MONVMENTVM

Member

Registered: 2007-10-06

Posts: 50

Re: Suspend/Sleep not working after disabling GDM

There are currently many people reporting sleep/suspend issues. I guess we'll have to wait for an official fix.

TheCoon

Member

Registered: 2016-05-10

Posts: 42

Re: Suspend/Sleep not working after disabling GDM

There are currently many people reporting sleep/suspend issues. I guess we'll have to wait for an official fix.

Oh, I wasn't aware. None of my colleagues are experiencing this, so I thought it was just me.
Is it likely kernel-related or systemd-related? Or some other package? I would think that my downgrading of systemd and linux-lts would solve the issue. Was there another package I should have downgraded?

ankhmor

Member

Registered: 2019-12-17

Posts: 2

Re: Suspend/Sleep not working after disabling GDM

I'd also like to know on the progress and where to check for updates

glitsj16

Member

Registered: 2015-04-26

Posts: 126

Re: Suspend/Sleep not working after disabling GDM

I assume you already checked the wiki page on suspend (especially the troubleshooting section). It's a sad reality that suspend/sleep gets broken very often. What helped me in those situations is to have some sort of debug log. To that end you could try creating a systemd override like the one below:

/etc/systemd/system/systemd-suspend.service.d/debug.conf

[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-sleep suspend; sh -c 'dmesg -T | grep Freez -A4 >> /var/log/suspend.log 2>&1'

HTH

TheCoon

Member

Registered: 2016-05-10

Posts: 42

Re: Suspend/Sleep not working after disabling GDM

I assume you already checked the wiki page on suspend (especially the troubleshooting section). It's a sad reality that suspend/sleep gets broken very often. What helped me in those situations is to have some sort of debug log. To that end you could try creating a systemd override like the one below:

/etc/systemd/system/systemd-suspend.service.d/debug.conf

[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-sleep suspend; sh -c 'dmesg -T | grep Freez -A4 >> /var/log/suspend.log 2>&1'

HTH

Thanks for the tip! I was actually looking for a way to do exactly that, so it may help me out the next time an issue like this arises.

I'm cautious about saying this, but at the moment it seems like the issue has been resolved. My uptime is now at exactly 4 days, and I've successfully suspended the system several times over these last few days, with heavy usage over the last 2 days. I even suspended once while writing this post just to make sure I didn't jinx it.

Currently running versions:
- Kernel: 4.19.91-1-lts
- systemd: 244 (244.1-1-arch)
- linux-firmware: 20191220.6871bff-1 (installed version, not sure what I booted with)

Fingers crossed it doesn't suddenly break again. If it does, I have glitsj16's method to try out.