Idle-culler when spawning jupyter-remote-desktop-instances from Jupyterhub

When serving Jupyter Remote Desktops (GitHub - jupyterhub/jupyter-remote-desktop-proxy: Run a Linux Desktop on a JupyterHub) through JupyterHub, are they compatible with the idle-culler service (GitHub - jupyterhub/jupyterhub-idle-culler: JupyterHub service to cull idle servers and users).
Not being too familiar with the internal architecture and trying to read up on it I found this quote from the TLJH documentation:

JupyterHub pings the user’s notebook server at certain time intervals. If no response is received from the server during this checks and the timeout expires, the server is considered to be inactive (idle) and will be culled.

I am not sure how the notebook server listens and replies to these messages (are they just regular network pings as I would create them with the ping command? If so, why would the notebook server ever stop responding?) and what happens if I don’t run a notebook but a remote desktop proxy?
As the remote desktop proxy is based on a jupyter/base-notebook docker image, will the base-notebook image contents have the appropriate services running to reply to the “idle” checks?
Does it even make sense to try and use the idle-culler with jupyter desktop images?

Edited to add:
This is running Z2JH with Kubespawner, just to avoid confusion as I quoted from the TLJH documentation.

The docs aren’t quite accurate in that JupyterHub doesn’t poll servers for activity, rather servers post activity to JupyterHub.

But Jupyter Server Proxy (on which desktop-proxy is based) does indeed include websocket messages in the tracked activity that should keep a server from being considered idle.

1 Like