`before-notebook.d` hook causes server timeout

JupyterHub
, ,
1

:wave: I haven’t been able to find anything that specifically gets at this problem.

c.Spawner.http_timeout = 30  # or whatever number of seconds to wait

The hook I have running attempts to install kernels for every virtual environment (whether it’s Python or Julia). This can take a non-trivial time, but I’m curious if there’s a way to sidestep the need to specify a really long http_timeout (in my case, setting it to 300 seconds is sufficient, but depending on the number of virtual environments that exist, it might not be enough).

I certainly understand the need to specify an http_timeout for spawners, however, the hooks aren’t actually related to the spinning up a singleuser notebook. So it seems a little odd to me that the http_timeout is intended to cover any and all things leading up the launch, since some of these things could be variably long. (e.g., I have 12 virtual environments, whereas the other users on my server only have 2-4, at the moment.)

So, my questions:

  1. Is it possible to specify a timeout that strictly considers the attempt to launch the server and not the hooks?
  2. If there isn’t anything like this, what might be some approaches that could allow for similar behavior to this? (I’m not super familiar with JupyterHub, so I’m at a loss as to whether there might be some way to signal to JupyterHub (from the singleuser server) that things went wrong, but otherwise allow an unlimited timeout – this last bit feels very wrong to do, but that’s also a pretty arbitrary feeling.)
2

before-notebook.d isn’t a standard feature of JupyterHub or JupyterLab. Are you using a container image from Jupyter Docker Stacks — Docker Stacks documentation ? If so the hooks are a feature of the image, and they’re run before the main JupyterLab (or notebook) server is launched.

You could perhaps try running your commands in the background?

3

I’m using the datascience-notebook from docker-stacks, yes.

I think they could be run as background tasks iff JupyterLab (in my case) can retrieve new kernels post-launch, without a restart? (I don’t recall if they can – it’s been a very long time since I’ve needed a kernel after I launched a server.)