system76-nm-restart sleep hook triggers ~90s systemd daemon-reload stall on resume, delaying lock-screen unlock (Pop!_OS 24.04, MediaTek Wi-Fi)

[FullOfBologna]

Summary

The system76-nm-restart system-sleep hook (added in 2016 as a workaround for Intel Wi-Fi modules on Xenial, per the changelog restarts NetworkManager ~1 second after every resume. On Pop!_OS 24.04 with systemd 255 + netplan, that restart triggers a systemctl daemon-reload during the resume window. The reload races with the in-progress wake sequence, fails and stalls PID 1 for ~90 seconds. While PID 1 is stalled, systemd-suspend.service cannot finish and lock-screen authentication queues behind it — every wake costs the user 50–90 seconds before they can unlock.

On MediaTek MT7921/MT7922 systems the hook is also redundant: the newer system76-wifi-reload hook (PCI remove on suspend / rescan on resume) fully handles Wi-Fi re-initialization, and Wi-Fi reconnects in ~3 seconds without any NetworkManager restart.

System

• System76 Pangolin, Pop!_OS 24.04 LTS (COSMIC), systemd 255.4-1ubuntu8.15pop0
• AMD CPU/GPU (amdgpu), MediaTek MT7921 Wi-Fi (mt7921e, PCI 14c3:7961)
• system76-driver with both /usr/lib/systemd/system-sleep/system76-nm-restart and system76-wifi-reload installed

Evidence — failing cycle (hook active)

08:09:36 kernel: PM: suspend exit                                  ← kernel resume <1s, clean
08:09:37 sudo: COMMAND=/usr/bin/systemctl restart NetworkManager   ← system76-nm-restart fires
08:09:38 systemd[1]: Reloading requested ... (unit NetworkManager.service)
08:09:38 systemd[1]: Reloading...
08:10:30 cosmic-greeter: gkr-pam: unlocked login keyring           ← unlock, ~54s after lid-open
08:11:08 systemd[1]: Failed to fork off sandboxing environment for executing generators: Protocol error
08:11:08 systemd[1]: Reloading finished in 90209 ms.               ← PID 1 stalled 90 seconds
08:11:08 systemd[1]: Finished systemd-suspend.service              ← suspend "finishes" 92s after wake
08:11:08 systemd-logind: Operation 'suspend' finished.

Reproduced on a second cycle with the same signature (resume → NM restart → Reloading... → ~50–60s unlock delay).

Control: time sudo systemctl daemon-reload at idle completes in 0.306s — the stall only occurs when the reload is triggered mid-resume by the hook.

Evidence — fixed cycle (hook diverted out of system-sleep)

08:52:01 kernel: PM: suspend exit
08:52:02 systemd[1]: Finished systemd-suspend.service              ← suspend lifecycle done in ~1s
         (no NetworkManager restart, no Reloading anywhere in cycle)
08:52:05 NetworkManager: device activated (Wi-Fi reconnected, DHCP lease)
08:52:07 cosmic-greeter: gkr-pam: unlocked login keyring           ← ~6s lid-open to unlock

Confirmed across three consecutive suspend/resume cycles (~5–6s each), including a Wi-Fi band roam — system76-wifi-reload alone handles MT7921 re-initialization correctly.

Workaround applied locally

sudo dpkg-divert --rename --local \
  --divert /usr/lib/system76-nm-restart.disabled \
  /usr/lib/systemd/system-sleep/system76-nm-restart

(Note: renaming the file within the system-sleep directory does not disable it — systemd-sleep executes every executable in the directory regardless of filename.)

Suggested resolution

Gate system76-nm-restart to the Intel 7260-era hardware it was written for. On modern hardware (at minimum MediaTek systems covered by system76-wifi-reload) it provides no benefit while causing a 90-second PID 1 stall on every resume under systemd 255 + netplan.

Full logs of each test attached.

all-tests.log

[FullOfBologna]

Leveraged Fable5 LLM for troubleshooting process, but executed all tests personally, and pulled the logs, and edited the issue summary personally. Still, beware, some of this is still leveraging AI to generate some of the information. But this has been a year-ish long issue, that is now finally resolved for me, with now much much faster wake and log in.