First off, if you have end-users reporting their OOD shell app is disconnecting far more quickly than it used to, with the message…
Your connection to the remote server has been terminated.
…then you should know that there were a couple changes to how OOD handled inactive shell connections (over a couple of 3.1.x versions) and if you want backgrounded shell tabs to last longer than 5 (?) minutes, then you’ll have to make some configuration changes. TL;DR: you may need to create a config file for your shell app (at /etc/ood/config/apps/shell/env) and drop in the magic timeout string to specify your timeout, and may also (?) need to enable shell-ping-pong.
IF I read the following release notes and announcements correctly, “the new system” was probably (?) introduced in v3.1.0, then sorta nerfed in v3.1.9 to default to a safer security posture due to some unforeseen issues:
v3.1 release-notes: improved shell connections
The shell app has been updated so that shell sessions can last longer. The app is better at keeping the connection alive, meaning users will maintain shell sessions for longer.
This, however, is disabled by default since 3.1.9. You can see more details in Enable and configure Shell Ping Pong.
Better shell connectivity.
Ping Ponging. Ping ponging in the shell application has been disabled by default. When ping ponging is enabled, the shell connection can stay active for longer than the authentication session. Open OnDemand version 3.1 added this feature, but after unanticipated findings of the shell session continuing after the authentication token expired, we have decided to turn ping ponging off by default.
I think that decision was fair but I don’t think it was clear to many of us that this series of changes could add up to complaints from users. But before I make too many assumptions, I want to ask for some clarifications:
- am I correct in concluding that idle shell apps are effectively treated differently since v3.1, at least from an end-user’s perspective?
- when pingpong is disabled: will v3.1 neither use “the new system”, nor failover to “the old system”?
(i.e. will Apache appear to close connections more aggressively than in v3.0?) - is enabling OOD_SHELL_PING_PONG indeed always required for OOD_SHELL_INACTIVE_TIMEOUT_MS & OOD_SHELL_MAX_DURATION_MS to have any effect? (testing inactive_timeout actually seemed to help my v3.1.15 system just now, even though pingponging is disabled, which confuses me)
- are both of the two points above true for both v3.1 and v4.0?
I’m asking because in some other related posts, Jeff mentions one needs to enable pingpongs otherwise INACTIVE_TIMEOUT_MS & MAX_DURATION_MS are disabled entirely. But I don’t think this is made clear by the shell-ping-pong docs. (To my ear, “In addition to enabling or disabling ping pongs, there are other settings you may wish to change” sounds like pingpong is optional.)
It also sounds like, since v3.1, nothing will actively keep idle shells active when pingpong is disabled because OOD does not fall-back to whatever was done in “the old system”…
[from /etc/ood/config/apps/shell/env] OOD_SHELL_INACTIVE_TIMEOUT_MS=600000 [but] The connection to the shell session has been terminated in < 1 minute
…
You have to enable ping pongs by setting the OOD_SHELL_PING_PONG environment variable. Otherwise, they’re disabled entirely.
oct 2024 Shell access timeout after 60secs
Upgraded to 3.1.9 and now the shell timeout less than a minute.
…
Is there any way to completely disable this behavior and return to the old style that didn’t disconnect?
…
No, and you can blame me personally for this if you like. I made the decision to disable it by default because I figured we (the developers/maintainers) need to be conservative in the defaults
…
Also, I’ve implemented …/shell/env file, with the two setting, but without enabling ping pongs. I’ve had two sessions fail under these conditions.
…
You need to enable ping pongs to keep the connection alive. Otherwise you’d need some trick like backgrounding something that prints stuff at regular intervals or similar. apache’s going to disconnect the connection after 60 seconds if there’s no traffic (pings and pongs are the traffic that will keep the connection alive).
Thanks in advance for any clarifications here!
(And sorry for any bad conclusions above! I’ll fix up any misdirection as I’m corrected!)
-jason