_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI Keeping SSH sessions alive with systemd-inhibit
fpoling wrote 38 min ago:
This has the same purpose as caffeinate command on Mac and will prevent
the system from suspend while a command is running. This is useful with
tmux or long compilations or tests or whatever.
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.
JdeBP wrote 1 hour 39 min ago:
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 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.
* [1] *
URI [1]: https://github.com/systemd/systemd/blob/main/src/login/logind-...
URI [2]: https://github.com/systemd/systemd/blob/main/src/login/logind-...
1970-01-01 wrote 2 hours 15 min ago:
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. [1]
URI [1]: https://www.golinuxcloud.com/keep-alive-ssh-sessions-in-linux/...
URI [2]: https://en.wikipedia.org/wiki/Keepalive
zokier wrote 2 hours 24 min ago:
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.
1oooqooq wrote 2 hours 35 min ago:
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.
ajross wrote 1 hour 16 min ago:
That's fine. In fact you're right that laptop and desktop power
management is generally best done manually by expert users. That how
I have things set up too, more often than not.
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.
blueflow wrote 3 hours 0 min ago:
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.
jeroenhd wrote 2 hours 36 min ago:
systemd doesn't kill your SSH session (if you'd WoL your PC there's a
good chance you can continue typing unless your local terminal
detects that the other end goes down).
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 wrote 2 hours 24 min ago:
Unwarranted suspends by logind have always been a menace, i have
been fighting them for a decade.
> 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 wrote 1 hour 16 min ago:
> SSH is a "legacy protocol" and its users are "uneducated
troglodytes",
Who are you quoting here?
bheadmaster wrote 45 min ago:
I assume that's a parody on systemd developers' attitude
towards The Unix Way (TM).
This github issue comes to mind:
URI [1]: https://github.com/tmux/tmux/issues/428
jon-wood wrote 2 hours 44 min ago:
I think the authorâs point was that this is usually desired
behaviour because itâs a desktop and only occasionally do they want
to stop that.
DIR <- back to front page