Docker-stacks: Feature: restartable Jupyter in container

[kafonek]

I do not know the most elegant way to implement this, so I'm posting an issue instead of a PR. I would like to be able to restart Jupyter within the docker-stacks container without the docker process ending because the ENTRYPOINT/CMD exited. That is to say, if I ran a notional command docker run -p 8888:8888 jupyter/base-notebook --restartable, then when I hit the 'Quit' button the Jupyter process would exit and restart without the docker container stopping.

One example of when it is necessary to restart the Jupyter process is after installing Jupyter serverextensions such as voila.

In many cases, a user can docker start a container after it has been stopped (effectively restarting Jupyter and the container) but there are times when a user does not have control over docker orchestration.

Thank you.

[parente]

There was an attempt to support SIGHUP to restart the Jupyter server without having the container exit in https://github.com/jupyter/docker-stacks/issues/309. If you or someone else is manages to get that approach working, or another one that does not complicate the image definitions, I'd be happy to review a PR.

[jeffyjefflabs]

You could do it with run-one-constantly. Just add run-one to the apt installs (looks like about 45K in size) and then you can either do this if you want it unconditionally:

diff --git a/base-notebook/start-notebook.sh b/base-notebook/start-notebook.sh
index b38c738..d24855a 100755
--- a/base-notebook/start-notebook.sh
+++ b/base-notebook/start-notebook.sh
@@ -8,7 +8,7 @@ if [[ ! -z "${JUPYTERHUB_API_TOKEN}" ]]; then
   # launched by JupyterHub, use single-user entrypoint
   exec /usr/local/bin/start-singleuser.sh "$@"
 elif [[ ! -z "${JUPYTER_ENABLE_LAB}" ]]; then
-  . /usr/local/bin/start.sh jupyter lab "$@"
+  . /usr/local/bin/start.sh run-one-constantly jupyter lab "$@"
 else
-  . /usr/local/bin/start.sh jupyter notebook "$@"
+  . /usr/local/bin/start.sh run-one-constantly jupyter notebook "$@"
 fi

or something like this if you want it to be optional:

diff --git a/base-notebook/start-notebook.sh b/base-notebook/start-notebook.sh
index b38c738..a6e6241 100755
--- a/base-notebook/start-notebook.sh
+++ b/base-notebook/start-notebook.sh
@@ -4,11 +4,17 @@

 set -e

+if [[ "${RESTARTABLE}" == "yes" ]]; then
+  wrapper=run-one-constantly
+else
+  wrapper=""
+fi
+
 if [[ ! -z "${JUPYTERHUB_API_TOKEN}" ]]; then
   # launched by JupyterHub, use single-user entrypoint
   exec /usr/local/bin/start-singleuser.sh "$@"
 elif [[ ! -z "${JUPYTER_ENABLE_LAB}" ]]; then
-  . /usr/local/bin/start.sh jupyter lab "$@"
+  . /usr/local/bin/start.sh $wrapper jupyter lab "$@"
 else
-  . /usr/local/bin/start.sh jupyter notebook "$@"
+  . /usr/local/bin/start.sh $wrapper jupyter notebook "$@"
 fi

Happy to submit a PR with either of those options. However, I'm getting an error in the conda installation step while building base-notebook (even without any of my changes), so I can't do a complete test of the docker build. But I can build a child image on top of base-notebook with these changes and it works fine.

I looked at #309 and SIGHUP seems to cause Jupyter to exit for me, not reload, hence this approach with run-one-constantly.

[parente]

TIL about run-one-constantly. Thanks @jeffyjefflabs. I'm happy to take a PR with your second approach so that we don't change the current default behavior. We can note the flag in the
documentation.

I think the build failures have been fixed recently. You can try again locally or submit the PR and we can see what happens on travis.

[ericdill]

Is there a version of run-one-constantly that is for centos 7? (This would be super super useful to have on my centos images :) Thanks for showing this pattern @jeffyjefflabs!)

[jeffyjefflabs]

I just stumbled across it recently while looking at this issue. Things like monit or supervisor seemed too heavyweight, so I was just going to write a bash script but then I found run-one-constantly. I'm not aware of a CentOS version, but it's just a shell script and there's a mirror on GitHub. The author also has a blog post about it.