-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Server connected to via SSH culled by inactivity - can we avoid it? #67
Comments
To avoid an server where we have an active ssh connection from being culled, I think the ssh server code here needs to send some 'ping' packets at regularly timed intervals. Should not be too difficult to do. |
Are you trying to stimulate activity as registered by the proxy server then? Hmmm... Is the networking something like: A users local computer establishes a SSH connection (-> autohttps) -> jupyterhub-ssh server -> proxy pod / configurable-http-server via http -> user server via http If that is the case, the proxy pod would receive http traffic, and that would make the server seen as active again I think. I'm asking to understand the mechanism of activity you hope to stimulate better. |
There were some confusion that led to this issue being opened. I'm not sure if a jupyterhub-ssh based connection will or won't lead to inactivity. I'm also unsure if SSH configuration (
@yuvipanda do you think TCPKeepAlive or similar configuration, at some place, would activity to be ensured when connections are open? Action points
|
As initially reported in pangeo-data/jupyter-earth#105, I think the
jupyterhub-idle-culler
fails to recognize that a user may be active via a SSH connection when usingjupyterhub-ssh
. Is this something we can avoid?I'm not feeling confident about if we can, or how we would go about it. Very related reading is the
jupyterhub-idle-culler
's README's How it works section though.As a workaround, I've suggested visiting the user server via a typical Jupyter UI, opening a notebook, and running something like
import time; time.sleep(3600*24*7)
to make a kernel stay running, which would block the culler logic.The text was updated successfully, but these errors were encountered: