I have installed OpenSuse Leap 15 just a few days ago. Ran updates in a daily bases since then…
Frequently when I have some apps opened, laptop has hard time suspending or hibernating(doesn’t matter if I try graphically or via CLI).
As I have noticed some apps are causing this. Last time it was Microsoft’s Visual Studio Code. I had remote folder mounted using sshfs, and I was editing file from that mounted folder inside vscode. Then because of inactivity, sshfs connection apparently got closed, and so inside editor were files which didn’t exist.
After that I was unable to suspend/hibernate my os. Screen turns off, am getting logged out, but processes still running.
I don’t think issue is with just vscode. I think other apps might cause same issue with right conditions.
Is there a setting to change, so no app will be able to stop Linux from suspending/hibernating?
I guess you could investigate taking steps to ensure the the remote filesystem is not disconnected (if that is the underlying cause of the problem here). The ‘ServerAliveInterval’ can be configured explicitly (in ~/.ssh/config for example) to send null packets after a given number of seconds. (By default, no null packet is sent, so inactivity will generally result in a disconnect depending on how the server is configured.)
Eh, this might be a different situation, but not that different in that I can suspend ( i never use hibernation ) and resume properly. I don’t use sshfs, but rather a Networkconnection over sftp through Dolphin - Network - Create New Connection. If uses kNetattach and can use various protocols. For my webapp development I use Kate. After creating the new Connection ( with a proper name f.e. Knurpht-VPS ), I drag it to Dolphin’s Places in the side bar. Now, from Kate I can open a file by clicking File - Open - click in Places on Knurpht-VPS and open as many files as my project requires, edit and save them. So far the use case, so you see it’s about the same: working on a remote project.
Now, I don’t work continuously on the same code, have the routine to close the lid of my laptop, which puts it to suspend. If I open the lid again, unlock, I can see the network connection be reeastablished and the entire Kate session is intact, i.e. I can change and save files, no data loss.
I haven’t encountered a situation like this (and I’m not familiar with vscode at all), so can only provide general advice here. Since you categorically state that it prevents suspend (and I assume shutdown) from occurring, I’m wondering if perhaps it is using a systemd inhibitor lock perhaps? This is complete speculation on my part though.
I note that there are two PolKit policies that can be tweaked to prevent user applications from having the ability to block or delay such an action
‘org.freedesktop.login1.inhibit-block-sleep’ and ‘org.freedesktop.login1.inhibit-delay-sleep’, and the default policies are as follows
# pkaction -av org.freedesktop.login1.inhibit-block-sleep
org.freedesktop.login1.inhibit-block-sleep:
description: Allow applications to inhibit system sleep
message: Authentication is required for an application to inhibit system sleep.
vendor: The systemd Project
vendor_url: http://www.freedesktop.org/wiki/Software/systemd
icon:
implicit any: no
implicit inactive: yes
implicit active: yes
annotation: org.freedesktop.policykit.imply -> org.freedesktop.login1.inhibit-delay-sleep org.freedesktop.login1.inhibit-block-idle
# pkaction -av org.freedesktop.login1.inhibit-delay-sleep
org.freedesktop.login1.inhibit-delay-sleep:
description: Allow applications to delay system sleep
message: Authentication is required for an application to delay system sleep.
vendor: The systemd Project
vendor_url: http://www.freedesktop.org/wiki/Software/systemd
icon:
implicit any: yes
implicit inactive: yes
implicit active: yes
#
As well as this, there is an option to limit ‘delay’ inhibitor locks to a maximum time interval. (This won’t have any effect if a ‘block’ inhibitor is employed though.)
InhibitDelayMaxSec=
Specifies the maximum time a system shutdown or sleep request is delayed due to an inhibitor lock of type “delay” being active before the inhibitor is
ignored and the operation executes anyway. Defaults to 5.
