computer is on, it's on. lid close, screen is off. done.
The use case for wakelocks (a longtime Android feature from which this is conceptually derived) is phones, though. Send a quick snap, throw it in your pocket, and expect (1) you get the notification for the reply when it arrives and (2) the device lasts until it gets back to the charger at bedtime.
That's highly non-trivial and absolutely not amenable to manual power management. Is systemd the right answer? Maybe not, but that's clearly where the feature is aimed.
(Also I have to quibble with the "very specific use case" idea: it's the standard use case. Laptops are the weird and rare edge cases these days.)
If you want to be extra fancy, you could even write small program that calls the dbus api directly and then just waits to be killed. Avoids the turducken of waiting processes.
https://www.golinuxcloud.com/keep-alive-ssh-sessions-in-linu...
The author wants xyr system to not suspend either when there's someone active on the GUI or when xe is logged in over the network. Theoretically, systemd already has a whole mechanism for making this happen.
The pam_systemd.so hook into PAM allows systemd-logind to track SSH sessions in its replacement for the Unix login database — all of that stuff under /run/systemd/users/, /run/systemd/seats/, and /run/systemd/sessions/. And in theory systemd-logind could respond negatively to a suspend request if there is an active SSH login session even if the GUI is idle.
In practice, it does not quite have the logic for achieving this. It's close, but it does not pass around enough information for this to be done as, say, a PolicyKit rule.
* https://github.com/systemd/systemd/blob/main/src/login/login...
* https://github.com/systemd/systemd/blob/main/src/login/login...
On Linux I rather prefer to configure my laptop to never suspend when connected to a power supply. For me the compilations and tests heavily drain battery and should not be run typically on battery.
But it turned on Mac Apple really wants to suspend and configuring the same behavior is somewhat non-trivial. So in past when I used Mac i often had a terminal window running
caffeinate -i sleep infinity
to prevent any suspend until I hit Ctrl-C there.
Cool trick though! I didn't know about systemd-inhibit.
blueflow•4mo ago
Consider disabling suspend from the logind.conf and suspend, if at all, only at explicit user request.
jon-wood•4mo ago
jeroenhd•4mo ago
It's more that when you configure systemd to suspend your computer when there is no physical activity, it will suspend your computer when there is no physical activity.
The author wants their computer to suspend automatically.
I think modifying your system configuration to never suspend is a much worse solution than using the tool designed to prevent suspending the computer while a specific program is running to prevent suspending the computer while that specific program is running.
It'd be easier if `sshd` would permit you to wrap the incoming command line/shells so `sshd` would spawn your session with systemd-inhibit, but I don't think that's possible?
blueflow•4mo ago
> It'd be easier if `sshd` would permit you to wrap the incoming command line/shells so `sshd` would spawn your session with systemd-inhibit, but I don't think that's possible?
sshd already links against systemd (by distro patches, not per upstream) but since SSH is a "legacy protocol" and its users are "uneducated troglodytes", this is not going to happen.
I think this is because OpenSSH is an OpenBSD project, and both systemd and OpenBSD refuse to support each other.
wmanley•4mo ago
Who are you quoting here?
bheadmaster•4mo ago
This github issue comes to mind:
https://github.com/tmux/tmux/issues/428