We deployed junyperhub and all is working fine until …
(I’m a noob here - so my terminology might have to be improved)
As we are experimenting, we installed an extension on one user server.
When restarting the environment, spawning the user server got a timeout.
Another user server (which has not that extension), spawns without a problem.
How can we uninstall the extension from the server which doesn’t startup?
I just removed the home directory of the user, but I guess this is a bit drastic.
Are there other approaches.
It depends on how you installed the extension. If you installed the extension as a Python package, pip uninstall <extension> should work.
I’m using the docker environment provided by RattyDave
https://hub.docker.com/r/rattydave/jupyterhub
This runs jupyterhub, and adds a lot of kernels for our various use cases.
The installation of the extension was done through the extension menu of JupyterHub …
Does this clarify some?
Cheers for the details. What could have happened is that the extension that you have installed via JupyterLab frontend must have created some config files in $HOME/.jupyter folder (That is the default location of config files of JupyterLab/notebook). When you restarted the environment, I guess the config file persisted in the $HOME/.jupyter is expecting the extension to exist in the environment which is obviously not the case. So, clearing any config file created by the extension before restarting the environment is the way to go.
Which extension did you try to install? Check if it is creating any config files in the said location.
Will check this out.
The extension is jupyter-ai-chatgpt.
The fact that the server is not starting after cycling the environment has been raised as a separate question in that project.
Thanks a million
I disabled it by accessing the container, and run
jupyter serverextension disable --system jupyter_ai
This solves that problem.
Checking the logs for the single-user server should hopefully point to an informative error. Extensions aren’t meant to be able to break the server (they can break themselves all they want, though). It’s pretty likely to be a version compatibility problem, I think, but I suspect there may be actionable fixes in jupyter-server.