Upgraded to 3.1.9 and now the shell timeout less than a minute.
Set passenger pool timeout to 300 and 900 with no success
3.1.9 announcement should have said something about the shell app utilizing ping pongs to keep the connection alive.
Here are the docs for the same:
I set the inactivity timeout to 1 hour and max terminal life to 24 hours. I also enabled ping pongs to keep it alive. The terminal started at 8:48am and disconnected at 8:54am.
OOD_SHELL_INACTIVE_TIMEOUT_MS=36000000
OOD_SHELL_MAX_DURATION_MS=8640000000
OOD_SHELL_PING_PONG=true
Is there any way to completely disable this behavior and return to the old style that didn’t disconnect?
Kenny
Did you restart your webserver to pick up the new configs?
Hi Jeff 
Thanks for the quick reply.
Restart as in systemctl restart httpd? Or restart as in Developer menu Restart Webserver?
We first set ping pong = true and figured that disables the timers, update_ood_portal, then I logged out and logged back in. I was disconnected fairly quickly. I then added my long default timers and restarted webserver using the developer menu and I was disconnected as described earlier.
I’m trying one more time.
K
Yea restart the webserver in the help menu to pick up new application configurations.
Our situation isn’t quite so drastic. We’ve not implemented a config for the shell app previously. Obviously, now it is necessary. We had server maintenance Monday this week, and our ondemand was updated to 3.1.9.
Our shells have tended to last up to 30 mins or so, although some account holders report that for them the shells don’t last more than 5 mins.
Thanks to samagids and kenny for driving the discussion. And thanks Jeff for providing the doc to resolve the situation.
~ Em
Not sure what to say about folks getting kicked after 5 minutes. My only guess is their PUN didn’t bounce to pick up the new configurations.
I’m trying to replicate right now. I started this at ~11:06 EST and continue to get and send ping/pongs past 5 minutes (up to 11:19 in the screenshot).
So I can get past 5 minutes and will hold it there and update the thread later.
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 we provide here. I (the developer) need to distribute secure defaults so that someone’s not surprised when a shell session can last much longer (forever actually) than their authentication system would allow.
I’ve got a test running too, an idle inactive background tab has been going for 15 minutes now.
I believe in security defaults so no worries as I can think of situations where the timers can be helpful. I’ll be editing my defaults to more reasonable times when I’ve got this stable.
How did you get your network inspector to show that? Mine just sits with nothing reporting.
K
Yea it’s a bit funny. Once you have the tab open - hard refresh the page and then you should start seeing them. It’s like if the connection has already been made (or in the process of being made) when the developer tools is open it won’t report anything.
Ahh there we go. Does that reset the timers too?
K
Yea because it’s a new connection at that point.
Sorry, battling a cold this morning, so all is fuzzier than usual.
Is it adequate to implement the changes in a running ood session via the 'restart web server" from help menu? or is a httpd service restart necessary after all?
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.
No you shouldn’t need to restart httpd for any application configs (shell, dashboard or otherwise). The link to restart your webserver will restart your webserver, but if you need to bounce them all you need to issue the nginx_stage command.
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).
Jeff you caught my attention with nginx_stage command. How exactly do I do that and where is the documentation that describes how to affect all active site logins?
Thanks, Jeff – I’m testing on backup/dev server, and enabling the pong was an additional necessary step, as you report.
Nice that for the apps it’s not system-level invasive to reset.
Appreciate you!
1 Like
The documentation for this is here, though I admit, I see how it’s buried and not super discoverable.
IIRC the executable is at /opt/ood/nginx_stage/sbin/nginx_stage. That may not be 100% correct, but it’s definitely in /opt/ood.
1 Like
Thanks, Jeff. I do believe the timers are working fine now. Thanks for the help.
Kenny
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.