Of course systemd killing your SSH session is a intentional feature, not a bug.

Consider disabling suspend from the logind.conf and suspend, if at all, only at explicit user request.

i think i used a laptop for a few hours in my life before I decided to simply disable all autosleep features.

computer is on, it's on. lid close, screen is off. done.

I think this could be made into systemd (user) service fairly easily. Then you wouldn't need to worry about `disown` or tracking the PID, you'd just `systemctl --user start|stop prevent-sleep.service`

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.

Why not fix the keep alive time? Yes, there's no wrong way to do it, but IMHO the nix philosophy states you should at least try to stick your problem and your solution together.

https://www.golinuxcloud.com/keep-alive-ssh-sessions-in-linu...

https://en.wikipedia.org/wiki/Keepalive

Yes, this is a bodge. And yes, it should be unnecessary to jam in an inhibitor lock taken around the lifetime of an interactive shell permanently in the background.

The author wants xyr system to not suspend when either 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.

* https://github.com/systemd/systemd/blob/main/src/login/login...

* https://github.com/systemd/systemd/blob/main/src/login/login...