search

jupyter-xeus / xeus-octave

Jupyter kernel for GNU Octave
https://xeus-octave.readthedocs.io/
GNU General Public License v3.0
57 stars 10 forks source link

Binder via xvfb cannot run multiple instances of the kernel #72

Closed rapgenic closed 1 year ago

rapgenic commented 1 year ago

I have noticed running the binder you have built, that you cannot run multiple notebooks in parallel, and the reason seems to be that xvfb-run refuses to start when another instance is running.

I haven't tried this, but I'd suggest running the whole binder under xvfb instead of the single kernel (e.g. starting jupyter lab with xvfb-run jupyter lab if binder allows for it)

AntoinePrv commented 1 year ago

Thanks for reporting.

Starting jupyter lab with xvfb-run jupyter lab if binder allows for it

I have not found an easy way to do this. Perhaps we could apply the same trick that is applied to xoctave but to jupyterlab (and hope this is the command that is used and not python -m ...).

rapgenic commented 1 year ago

Another possibility looking at the binder documentation might be to create a custom Dockerfile, that inherits the main binder docker image and replaces the jupyter lab entrypoint by xvfb-run jupyter lab

AntoinePrv commented 1 year ago

Could you share that link?

AntoinePrv commented 1 year ago

Looks like we could also launch the server as a background process, but I don't think this is feasible during image creation, so we still need to hack to launch it.

https://elementalselenium.com/tips/38-headless (Option 1)

rapgenic commented 1 year ago

Actually this seems to be a lot simpler:

https://mybinder.readthedocs.io/en/latest/using/config_files.html#start-run-code-before-the-user-sessions-starts

The start script seems to be an entrypoint (it must end in exec $@). I suppose we could either write exec xvfb-run $@ or start xvfb in the background and then set the DISPLAY environment variable