Binder displays 500 internal server error when launching a built image

Binder
1

I am trying to run an image from this repository (Dockerfile-based):

on mybinder. I need to use Dockerfile because I am trying to run a legacy project that it’s not working with recent jupyter notebook versions. Therefore I download old anaconda distribution, that I know is compatible with my notebook. I use the instructions from binderhub to create the dockerfile. The image builts and runs fine on my machine. It’s also builit sucessfully on mybinder, but when I try to launch it, I get “500 Internal server error”. I tried a few modifications (install dirs, user permissions etc.) in the Dockerfile, but the result is always the same.

I tried also running the repo with my private deployment of binderhub (setup using the instructions from “Zero to BinderHub”), and the image builds/runs fine (temporary link, that will stop working soon):

http://34.67.69.53/v2/gh/btel/jupyter-dashboards-binder/master

Would it be possible to investigate the logs of the mybinder to better understand what’s happening?

Big thanks in advance!

Bartosz

3 Likes
2

https://gist.github.com/betatim/0e96f4dc53785b4fe5c310880afc4c2a is what I see in the logs if I try and start the repo you linked to.

Do you see this when you run it locally with master of repo2docker?

2 Likes
3

Thanks for your help in investigating this issue.

Running repo2docker master branch locally works fine. It opens a jupyter notebook with a directory tree.

From the logs I see that mybinder instance crashes on rendering a jinja2 template. Apparently, there is a problem with the template in file "/etc/jupyter/templates/tree.html

I have no idea, where this template comes from. In the image built locally with repo2docker this file does not even exist. Any ideas?

Bartosz

4

We inject that from https://github.com/jupyterhub/mybinder.org-deploy/blob/1f6924b9f877d1a47cdb28dbadf00d744b7255ca/mybinder/files/etc/jupyter/templates/tree.html and indeed a local repo2docker run wouldn’t have that nor would your own BinderHub.

If you have a moment to investigate a bit further and maybe make a suggestion what we can do or even make a PR that would be super!

We recently changed the templates to add buttons to the top right of the UI to help people with sharing their Binders. People used to share the wrong link which lead to confused people when they followed them.

1 Like
5

It seems that the internationalization ({% trans %} tag) was introduced in notebook 5.1. I upgraded from 5.0 to 5.1 and it works perfectl! Thanks a lot for help!

There are not many solutions to make the template compatible with notebooks prior to 5.1:

  1. remove internationalization (but I guess not an option),
  2. patch jupyter < 5.1 to add jinja2 i18n extension – not maintainable,
  3. mention that notebook > 5.1 is required in the docs

Unfortunately, I don’t find any way to make the {% trans %} tag conditional, i.e. only include it in the template if the extension is loaded.

2 Likes
6

Not being able to run things with old notebook servers sounds ok but also a bit annoying.

Two things I’m wondering:

  • can we somehow overwrite/ignore/modify the template from your Dockerfile?
  • can we setup the config of the notebok server so that for older versions it uses a different directory to search for templates?
7

Two things I’m wondering:

  • can we somehow overwrite/ignore/modify the template from your Dockerfile?

I assume that the template is injected at the end of the build process, so it will overwrite anything we put in the folder before.

  • can we setup the config of the notebok server so that for older versions it uses a different directory to search for templates?

Perhaps, we could tweak the search path of notebook server, but /etc/jupyter is one of defaults, which does not seem to be configurable:

https://jupyter.readthedocs.io/en/latest/projects/jupyter-directories.html

Alternatively, one could modify mybinder deployment scripts to inject the templates only for notebook >= 5.1 (or inject a different version for notebook < 5.1).

Bartosz

8

Using the JUPYTER_CONFIG_DIR environment variable maybe?

9

I tried this, but unfortunately it keeps the default paths:

jovyan@70c7a85ba7b5:~$ JUPYTER_CONFIG_DIR=/home/hello jupyter --paths

config:
    /home/hello
    /home/jovyan/anaconda/etc/jupyter
    /usr/local/etc/jupyter
    /etc/jupyter
data:
    /home/jovyan/.local/share/jupyter
    /home/jovyan/anaconda/share/jupyter
    /usr/local/share/jupyter
    /usr/share/jupyter
runtime:
    /home/jovyan/.local/share/jupyter/runtime
10

Can we detect (reliably) the version of the notebook server in a jupyter config file? Then we could put the templates in a new directory that isn’t on the search path by default and for notebook > v5 we add that path to the search path? So it is a opt-in for “new enough” versions.

Thanks for helping out with ideas and actually trying stuff!

2 Likes
11

I just opened a PR 1247 with the resolution to the issue.

The solution proved to be very simple. I found an option in jupyter_notebook_config that allows to inject variables into jinja environment. With this option, one can add the i18n extension to jinja templates in notebooks prior to 5.1.0 (tested with 5.0.0). QED

2 Likes
12

For future reference, here is the relevant page in jinja docs:

https://jinja.palletsprojects.com/en/2.10.x/extensions/

13

This is a nice solution! Super cool!