-
Notifications
You must be signed in to change notification settings - Fork 80
Allow user servers to start even with disks full #7077
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
base: main
Are you sure you want to change the base?
Allow user servers to start even with disks full #7077
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
|
I was looking at why migrate was being called at all, and found https://github.com/jupyter/jupyter_core/blob/2e63fd3928a979844fa0c2a247ee1937bbae9a99/jupyter_core/application.py#L166 as the likely culprit. But that looks like it should handle not being able to write Can you tell me when the I agree that we should not screw up workspaces if we can avoid it. I'll note that workspaces can be set separately via https://github.com/jupyterlab/jupyterlab_server/blob/f64f554291a09f072e479ff52ae2212084aaac39/jupyterlab_server/config.py#L273 as well it looks like. |
|
@yuvipanda, the server does start if This is the fatrace output from when starting a server, then trying to open up a new notebook, while I had reached the quota I had set for my username. |
|
The I believe this is the case when there's a user trying to start up their server for the first time on a full homedir disk and not when they are hitting their quota. Otherwise, the Then solving this would be solving 2i2c-org/jupyterhub-home-nfs#41? Is there something that I'm missing here that I'm not able to reproduce this with the quota? |
|
2i2c-org/jupyterhub-home-nfs#41 should be unrelated, as that's mostly about the underlying disk when it's 100% full, rather than anything about an individual user's quota. |
|
So I filled up my openscapes staging hub quota, and looking at logs, I see: However, the server starts. So it looks like none of these are blockers to the server actually failing! However, I filled up my cloudbank staging hub, and in logs I see: So that's coming from https://github.com/jupyterhub/repo2docker/blob/main/repo2docker/buildpacks/repo2docker-entrypoint. I think the outcome of my investigation thus is:
I think the path forward here is:
|
Fixes #6639
Running
fatraceshowed that the following files were written at startup:Unfortunaly, the
migrateddirname is hardcoded, so we have to put the entire.jupyterconfig in/tmp.Is that acceptable? I am thinking specifically if the workspaces are to be persisted, that this new setup will make it impossible.