Dear Lazyweb,
Sometimes some application prevents suspend on my laptop. I want to disable that feature: how?
I understand that there may exist some people who like that feature. I, on the other hand, consider a scenario like this inconceivable:
- I'm on a plane working with my laptop, the captain announces preparations for landing, so I quickly hit the suspend button (or close the lid) on my laptop and stow it away.
- One connecting flight later, I pick up my backpack, I feel it unusually hot and realise that my laptop has been on all along, and is now dead from either running out of battery or thermal protection.
- I think things that, if spoken aloud in front of a pentacle, might invoke major lovecraftian horrors.
I do not want this scenario to ever be possible. I want my suspend button to suspend the laptop no matter what. If a process does not agree, I'm fine with suspending it anyway, or killing it.
If I want my laptop to suspend, I generally have a good enough real-world reason for it, and I cannot conceive that a software could ever be allowed to override my command.
How do I change this? I don't know if I should look into systemd, upowerd, pm-utils, the kernel, the display manager or something else entirely. I worry that I cannot even figure where to start looking for a solution.
This happened to me multiple times already, and I consider it ridiculous. I know that it can cause me data loss. I know that it can cause me serious trouble in case I was relying on having some battery or state left at my arrival. I know that depending on what is in my backpack, this could also be physically dangerous.
So, what knob do I tweak for this? How do I make suspend reliable?
Update
Systemd has an inhibitor
system, and systemd-inhibit --list only lists 'delay' blocks in my system. It
is an interesting feature that seems to be implemented in the right way, and it
could mean that I finally can get my screen to be locked before the system is
suspended.
It is possible to configure the inhibitor system in /etc/systemd/logind.conf, including ways to ignore inhibitors, and a maximum time after which inhibitors are ignored if not yet released.
Try as I might to run everything that I was running on the plane that time, I could not manage to see anything take an inhibitor block that could have prevented my suspend. I now suspect that what happened to me was a glitch caused by something else (hardware? kernel? cosmic rays!) during that specific suspend.
When I had this issue in the past it looks like the infrastructure at the time was far more primitive that what we have now with systemd, so I guess that when writing my blog post I had simply correlated my old experiences with a one-off suspend glitch.
If I want to investigate or tune further, to test the situation with a runaway
block, I can use commands like systemd-inhibit --mode=block sleep 3600.
I'm quite happy to see that we're moving to a standard and sane system for
this. In the meantime, I have learnt that pm-utils has now become superfluous
and can be deinstalled, and so can acpi-support and acpi-support-base.
Thanks vbernat, mbiebl, and ah, on #debian-devel for all the help.