Docker Community Forums

Share and learn in the Docker community.

docker jupyter notebook address never responds / times out

docker

#1

Trying to use jupyter-notebook on a docker image (https://hub.docker.com/r/tensorflow/tensorflow), but having problem where using the port-forwarded address in browser just hangs with the (chrome) home page stuck saying Waiting for 127.0.0... until it just times out.

The docker command being run looks like

➜  ~ docker run -it -p 8888:8888 --rm tensorflow/tensorflow:latest-devel-gpu-py3 jupyter-notebook --ip 0.0.0.0 --no-browser --allow-root
[I 04:26:44.023 NotebookApp] Writing notebook server cookie secret to /root/.local/share/jupyter/runtime/notebook_cookie_secret
[I 04:26:44.042 NotebookApp] Serving notebooks from local directory: /root
[I 04:26:44.043 NotebookApp] The Jupyter Notebook is running at:
[I 04:26:44.043 NotebookApp] http://(f1afd4b163fd or 127.0.0.1):8888/?token=5a838cefbd58822ce3de5a9ab00ed724bc6f9e048017125a
[I 04:26:44.043 NotebookApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).
[C 04:26:44.043 NotebookApp] 
    
    Copy/paste this URL into your browser when you connect for the first time,
    to login with a token:
        http://(f1afd4b163fd or 127.0.0.1):8888/?token=5a838cefbd58822ce3de5a9ab00ed724bc6f9e048017125a

(note, have also tried docker run -it -p 8888:8888 --rm tensorflow/tensorflow:latest-devel-gpu-py3 /run_jupyter.sh --allow-root to similar hanging results).

Checking docker ps shows

➜  ~ docker ps
CONTAINER ID        IMAGE                                        COMMAND                  CREATED              STATUS              PORTS                              NAMES
2114609d6d9d        tensorflow/tensorflow:latest-devel-gpu-py3   "jupyter-notebook --…"   About a minute ago   Up About a minute   6006/tcp, 0.0.0.0:8888->8888/tcp   mystifying_liskov

Checking for a response via curl shows

➜  ~ curl -v http://127.0.0.1:8888/?token=5a838cefbd58822ce3de5a9ab00ed724bc6f9e048017125a
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8888 (#0)
> GET /?token=5a838cefbd58822ce3de5a9ab00ed724bc6f9e048017125a HTTP/1.1
> Host: 127.0.0.1:8888
> User-Agent: curl/7.47.0
> Accept: */*
> 

<at this point just hangs until I ctl+C out>


* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer

and examine the ports shows

➜  ~ sudo netstat -plnt
[sudo] password for me: 
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1512/sshd       
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      2485/cupsd      
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      2284/smbd       
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      1502/mysqld     
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      2284/smbd       
tcp        0      0 127.0.0.1:5037          0.0.0.0:*               LISTEN      8558/adb        
tcp        0      0 127.0.0.1:6000          0.0.0.0:*               LISTEN      1006/unicorn.rb --h
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      1954/monitorix-http
tcp6       0      0 :::22                   :::*                    LISTEN      1512/sshd       
tcp6       0      0 ::1:631                 :::*                    LISTEN      2485/cupsd      
tcp6       0      0 :::445                  :::*                    LISTEN      2284/smbd       
tcp6       0      0 :::8888                 :::*                    LISTEN      32491/docker-proxy
tcp6       0      0 :::139                  :::*                    LISTEN      2284/smbd       
tcp6       0      0 :::80                   :::*                    LISTEN      1846/apache2 

Other post I’ve seen seem to be people simply not forwarding the port that jupyter expects to use, but that does not seem to be the problem here. This occurs regardless of what docker image is used (so not just that particular image). If anyone has any ideas of what it could be or any debugging advice it would be appreciated.