I currently have a thinkpad (intel) and pretty much everything used to work just fine.
It used to be the case that if I close the laptop, it would go to sleep - I could see by the breathing red light in the lid for example. But now - I’m not sure since when - it looks like it “doesn’t go to sleep/suspend” anymore.
If I close the lid, the red light is full on. I noticed this morning as it drained all the battery.
Even more weird is, if I try to make it suspend, or close the lid, when it’s back on, the wifi adaptor is gone from gnome options (no network connection), although lspci still lists it. And suspend/reset/shutdown just don’t work. They become no-ops.
If I try by to shut it down by the console (after trying from the gnome menu) it tells that the action is already in progress.
does this ring a bell to anyone?
I tried to keep journalctl -x -f | grep --line-buffered -i error open during the “suspend/wake up” process, but it only flagged some flatpak errors 
I have a thinkpad (t470s) and it was doing that on 23.05 but not since I’ve recently updated to 23.11. What version are you running?
I’m currently running 23.11 already 
nixos https://nixos.org/channels/nixos-23.11
system.stateVersion = "23.11"
Did you do anything to debug it at the time?
I’m completely lost in terms of where is the problem coming from. Maybe gnome?
But the fact that after the “suspend” not even the physical power button works is so weird.
This is the only thing I see in the journal (filtering by ‘error’) after a suspend/wake up/login:
Jan 13 17:20:20 bebop .gnome-shell-wr[2962]: Failed to inhibit suspend: GDBus.Error:org.freedesktop.login1.OperationInProgress: The operation inhibition has been requested for is already running
Hmmm… I dont know. There’s some interesting stuff on Thinkpads, hibernate and suspend on the Arch wiki: Power management/Suspend and hibernate - ArchWiki
I found the solution!
completely crazy, but worth documenting here in case someone else runs into it. I also think this is a bug, but I’m not sure where to report it.
After some investigation, it seemed that the suspend was “broken” because it was waiting on the pre-sleep unit (from systemd):
/etc ❯❯❯ systemctl list-jobs ✘ 130
JOB UNIT TYPE STATE
3450 sleep.target start waiting
3449 systemd-suspend.service start waiting
3451 pre-sleep.service start running
3526 post-resume.target start waiting
3527 post-resume.service start waiting
3448 suspend.target start waiting
I went inside that unit to see what was going on, and it looks like in the end, the script it was executing was:
#!/nix/store/q1c2flcykgr4wwg5a6h450hxbk4ch589-bash-5.2-p15/bin/bash
set -e
#flush any bytes in pipe
while read -n 1 -t 1 SUSPEND_RESULT < /tmp/PmMessagesPort_out; do : ; done;
#suspend DisplayLinkManager
echo "S" > /tmp/PmMessagesPort_in
#wait until suspend of DisplayLinkManager finish
if [ -f /tmp/PmMessagesPort_out ]; then
#wait until suspend of DisplayLinkManager finish
read -n 1 -t 10 SUSPEND_RESULT < /tmp/PmMessagesPort_out
fi
So it seems that this was added there by the DisplayLink package (which manages super high resolution monitors). But in this case, I was using the laptop-solo, not connected to the dock or monitors. I think that was the problem.
For now I’ve removed the pre-sleep from executing completely by adding:
systemd.services."pre-sleep".wantedBy = lib.mkForce [ ];
to my configuration.nix.
This is not a real fix, as I don’t know yet what will happen when I connect it to the dock/monitors using displaylink. But it works for now, the laptop suspends and resumes correctly finally.
Anyidea if this is a bug on displaylink itself or in the nixos package?
1 Like