This is in reference to the “hanging suspend job prevents shutdown” bug.
On some more investigation, the problem seems to be with operating with the laptop lid closed (while it is plugged in to an external monitor). This is a standard usage for me. Upon booting, I usually close the lid at the login screen or after logging in. The laptop display goes off, everything gets transferred to the external monitor and life goes on an usual. This has led me to previously think that the system is smart enough to recognize that, as the external monitor is plugged in, it should not suspend. This may nbe the case, but if so, there appears to be a split personality: the OS initiates a sleep command and suspends it. It is this that causes all the issues.
The workaround is to get the OS to ignore the laptop lid being closed. Edit ‘/etc/systemd/logind.conf’, and replace (or just simply add after) the line:
And reboot or restart the service:
systemctl restart systemd-logind
And voila! No more issues regardless of whether or not the laptop lid is open or closed. Power modes (shutdown, suspend etc.) all work, network manager is available from the get-go, etc. etc. etc.
Of course, I presume this means that you cannot expect the system to suspend when you close your laptop lid and it is not connected to any monitors OR when you disconnect all external monitors from the laptop as it used to (and which, arguably, is desirable and expected behavior). Perhaps if we could have the HandleLidSwitch execute a script which uses
xrandr to see any external monitors are connected and only then suspend? But the difficulty then might be for the OS to know what the laptop native display ID is. In fact, I suspect that this could be the issue. If so, a prediction would be that everything Just Works (fine) for laptops which have standard ID (as given by xrandr,e.g. LVDS1), but not for others (e.g., my laptop display has “DP-0” for its output ID).