Description of problem: Running jupyter notebook results in a crash. $ jupyter notebook Traceback (most recent call last): File "/usr/bin/jupyter-notebook", line 6, in <module> main() File "/usr/lib/python3.6/site-packages/jupyter_core/application.py", line 267, in launch_instance return super(JupyterApp, cls).launch_instance(argv=argv, **kwargs) File "/usr/lib/python3.6/site-packages/traitlets/config/application.py", line 657, in launch_instance app.initialize(argv) File "<decorator-gen-7>", line 2, in initialize File "/usr/lib/python3.6/site-packages/traitlets/config/application.py", line 87, in catch_config_error return method(app, *args, **kwargs) File "/usr/lib/python3.6/site-packages/notebook/notebookapp.py", line 1368, in initialize self.init_webapp() File "/usr/lib/python3.6/site-packages/notebook/notebookapp.py", line 1188, in init_webapp self.http_server.listen(port, self.ip) File "/usr/lib64/python3.6/site-packages/tornado/tcpserver.py", line 141, in listen sockets = bind_sockets(port, address=address) File "/usr/lib64/python3.6/site-packages/tornado/netutil.py", line 196, in bind_sockets sock.bind(sockaddr) OSError: [Errno 99] Cannot assign requested address Version-Release number of selected component (if applicable): python3-notebook-5.2.1-1.fc27 How reproducible: every time Steps to Reproduce: 1. jupyter notebook 2. 3. Actual results: traceback Expected results: running session Additional info:
I cannot reproduce. Is there any output before the traceback? Could you add print(sockaddr) before sock.bind(sockaddr) into /usr/lib64/python3.6/site-packages/tornado/netutil.py (line 196)? Can you ping localhost? On IPv4, IPv6? Does `jupyter notebook --ip=0.0.0.0 --port=8080` work? Does `jupyter notebook --ip=127.0.0.1 --port=8080` work? Does `jupyter notebook --ip=::1 --port=8080` work?
(In reply to Miro Hrončok from comment #1) > Is there any output before the traceback? No > Could you add print(sockaddr) before sock.bind(sockaddr) into > /usr/lib64/python3.6/site-packages/tornado/netutil.py (line 196)? ('::1', 8888, 0, 0) > Can you ping localhost? On IPv4, IPv6? IPv4 yes, IPv6 is disabled > Does `jupyter notebook --ip=0.0.0.0 --port=8080` work? Yes! Finally something. > Does `jupyter notebook --ip=127.0.0.1 --port=8080` work? Yes! > Does `jupyter notebook --ip=::1 --port=8080` work? No. That is odd. It seems to prefer an IPv6 local address even though it's not available. And a traceback is not a good error message.
What's the output of `resolveip localhost`? Do you have some config in ~/.jupyter ? What happens when you move it away? Apparently, your notebook wants to use port 8888, which is IIRC not the default. The IP (::1) and port have to come from somewhere.
(In reply to Miro Hrončok from comment #3) > What's the output of `resolveip localhost`? I get: # resolveip localhost IP address of localhost is 127.0.0.1 IP address of localhost is 127.0.0.1 > Do you have some config in ~/.jupyter ? What happens when you move it away? This is what I see. $ ls -l ~/.jupyter/ total 8 -rw-rw-r--. 1 sgrubb sgrubb 26 Feb 7 15:57 migrated drwxr-xr-x. 2 sgrubb sgrubb 4096 Feb 8 07:24 nbconfig $ cat ~/.jupyter/migrated 2018-02-07T20:57:20.5 $ ls -l ~/.jupyter/nbconfig/ total 4 -rw-rw-r--. 1 sgrubb sgrubb 42 Feb 8 07:24 notebook.json $ cat ~/.jupyter/nbconfig/notebook.json { "Notebook": { "Header": true } } > Apparently, your notebook wants to use port 8888, which is IIRC not the > default. The IP (::1) and port have to come from somewhere. Just a quick browse shows port 8888 is default http://jupyter-notebook.readthedocs.io/en/stable/public_server.html I guess the main issue is that it preferred IPv6 over IPv4 even when IPv6 was not enabled. I suppose that is getaddrinfo's results list. But what I've seen as good practice for this situation is that code is supposed to iterate over the addresses returned by getaddrinfo trying each one until successful or the addresses are exhausted.
(In reply to Steve Grubb from comment #4) > Just a quick browse shows port 8888 is default Oh, you are right, sorry about that. This seems like an upstream bug then. Would you be willing to bring this to upstream, or shall I do it?
I filed: https://github.com/tornadoweb/tornado/issues/2274
Thanks. I will monitor that issue and backport the fix once ready.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.