Ipython: Socket-Fehler 99 für ipython-Notebook
Hi
Beim Versuch, ein Notebook zu öffnen, erhalte ich einen Socket-Fehler 99 "Angeforderte Adresse kann nicht zugewiesen werden". Dies geschah nach einem Systemupdate, obwohl Ipython nur von 2.1.0-62 auf 2.1.0-63 (SuSE-Paket) aktualisiert wurde, habe ich folgendes ohne Erfolg überprüft:
- überprüft, ob das Loopback-Gerät läuft (es ist mit inet addr:127.0.0.1 Mask:255.0.0.0)
- mit netstat -lp überprüft, ob Standardport bereits zugewiesen ist (war nicht)
- Führen Sie ein kleines Testskript aus, um den Tornado-Webserver an Port 8888 zu starten, es hat funktioniert
- Erstellen Sie ein Standardprofil und führen Sie ipython erneut aus
- ipython mit explizitem Host und (zufälligem) Port gestartet (ipython notebook --init --ip='localhost' --port=49151)
- Versucht ist als root
- Überprüft, dass die Firewall nicht blockiert
- Überprüft, ob ich in tmp schreiben kann (falls erforderlich)
Ich bin also ratlos, was ich noch tun kann. Jeder Hinweis, was ich noch tun kann, ist willkommen.
Die Startmeldung lautet
tmp/> ipython notebook --init --log-level=50 --ip='localhost' --port=49151 [15:46:39]
Traceback (letzter Anruf zuletzt):
Datei "/usr/bin/ipython", Zeile 5, in
start_ipython()
File "/usr/lib/python2.7/site-packages/IPython/ init .py", Linie 120, in start_ipython
return launch_new_instance(argv=argv, _kwargs)Datei "/usr/lib/python2.7/site-packages/IPython/config/application.py", Zeile 563, in launch_instanceapp.initialize(argv)Datei "
error: [Errno 99] Angeforderte Adresse kann nicht zugewiesen werden
Meine Systemkonfiguration ist
{'commit_hash': '681fd77',
'commit_source': 'Installation',
'default_encoding': 'UTF-8',
'ipython_path': '/usr/lib/python2.7/site-packages/IPython',
'ipython_version': '2.1.0',
'os_name': 'posix',
'Plattform': 'Linux-3.11.10-17-default-x86_64-with-SuSE-13.1-x86_64',
'sys_executable': '/usr/bin/python',
'sys_platform': 'linux2',
'sys_version': '2.7.6 (Standard, 21. November 2013, 15:55:38) [GCC]'}
Meine Tornado-Version ist
Name: Python-Tornado/Version: 3.2.1-2.1/Arch: x86_64
gluincth
Alle 13 Kommentare
Und was ist, wenn Sie --ip=127.0.0.1 versuchen?
minrk
am 23. Juli 2014
Hi
Das funktioniert (hätte daran gedacht). Ich habe es in meine ipython_notebook_config.py eingefügt. Ich frage mich aber, warum sich das Verhalten geändert hat...
Von meiner Seite aus konnte ich dieses Thema also schließen. Nur wenn man die Fehlermeldung in etwas Sinnvolles ändern könnte, das auf die Lösung hinweist, würde ich dieses Thema offen halten. Aber vielleicht ist dieses Problem zu spezifisch...
Vielen Dank für die schnelle Antwort!
gluincth
am 24. Juli 2014
Erklärung aus #6191 kopieren:
IPython lauscht standardmäßig auf localhost. 127.0.0.1 sollte sich gleich verhalten und tut es in fast allen Fällen. Einige Fälle, in denen dies anders gehandhabt werden kann, umfassen lokale Proxys und/oder Firewalls (normalerweise aufgrund einer Konfigurationsaufsicht und nicht aufgrund eines absichtlichen Verhaltensunterschieds). Wir haben Fälle gefunden, in denen localhost funktioniert und 127 nicht und umgekehrt, daher gibt es keine eindeutig richtige Antwort für die Standardeinstellung.
Haben Sie eine Firewall- und/oder Proxy-Konfiguration? Wenn ja, steuern Sie die Konfiguration? Ich würde dieses Verhalten als einen Fehler in Ihrem Netzwerk-Setup beschreiben, aber möglicherweise haben Sie keine Berechtigung zum Beheben.
minrk
am 24. Juli 2014
Danke, die Angabe von 127.0.0.1 hat den Socket-Fehler auch für mich behoben
naoko
am 17. Aug. 2014
Wenn Sie es in einem Cloud-Server verwenden, können Sie --ip=0.0.0.0 .
tigerneil
am 11. Dez. 2017
Vielen Dank, dass Sie dieses Problem beibehalten. Ich richte einen Notebook-Server auf einem Cloud-Server ein. Und die Angabe der Listening-IP als "0.0.0.0" löst das gleiche Problem.
Leegenux
am 23. Jan. 2018
Danke, ich hatte das gleiche Problem :)
OussamaSegh
am 23. Okt. 2018
danke es hat es gelöst!
Chichilele
am 13. Dez. 2018
Für Leute, die aus Suchergebnissen kommen: Überprüfen Sie Ihre /etc/hosts auf Tippfehler und IPv6-Konfiguration. localhost sollte nur auf IPv4-Loopback ( 127.0.0.1 ), nicht auf IPv6 ( ::1 ) zeigen. Dies kann andere Dinge zerstören, nicht nur Jupyter.
Das ist zum Beispiel falsch:
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
das ist in Ordnung:
::1 localhost6 localhost6.localdomain6
https://github.com/codenvy/codenvy/issues/2427#issuecomment -397347888
https://bugzilla.redhat.com/show_bug.cgi?id=211800#c4
mlazowik
am 21. Feb. 2019
@mlazowik Vielen Dank! Dies hat mein Problem gelöst - ich frage mich, wie viele andere das gleiche Problem haben, sich aber für die Lösung 127.0.0.1 entschieden haben. Dies ist die richtige Lösung (um sicherzustellen, dass die Nachschlagetabelle für den Hostnamen korrekt ist). In meiner Instanz (Arch Linux) wurde mein /etc/hosts wie folgt "versandt":
127.0.0.1 localhost.localdomain localhost
::1 localhost.localdomain localhost
Und ich habe es wie folgt korrigiert:
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
craymichael
am 3. Juli 2019
Wenn Sie es in einem Cloud-Server verwenden, können Sie
--ip=0.0.0.0.
Bei mir (auf Mac) funktioniert nur --ip=0.0.0.0 der lokal ausgeführte Docker.
0xfeedbac
am 3. Sept. 2019
In meinem Fall liegt es an der /etc/hosts für die doppelte ::1-Loopback-Adresse in IPv6.
Nachdem die zweite Loopback-Adresse ::1 auskommentiert wurde, ist der Fehler weg.
liho98
am 14. Dez. 2019
@mlazowik Ich hatte das gleiche Problem mit der gleichen eventuellen Lösung, fand es aber interessant, dass man /etc/hosts dies in ihrem Beispiel hat, was mich davon abhielt, mein Problem herauszufinden (da eine mutmaßliche Autorität genau das empfiehlt, was du sagst ist problematisch):
# The following lines are desirable for IPv4 capable hosts
127.0.0.1 localhost
127.0.1.1 thishost.mydomain.org thishost
[...]
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
Ich habe localhost aus dem Eintrag ::1 (die anderen beiden behalten) und alles ist gut. Ich nahm auch an, dass ip6 ein ipv6 Schlüsselwort ist, aber vielleicht sind ip6-foo und foo6 beide in Ordnung (zB nur eine Form der Namensverstümmelung gegenüber dem ipv4 Äquivalent)?
jwhendy
am 7. Jan. 2020
Verwandte Themen
okomarov
·
3Kommentare
RinaldoB
·
3Kommentare
henryiii
·
3Kommentare
ederag
·
3Kommentare
zhao-ji
·
4Kommentare
Hilfreichster Kommentar
Und was ist, wenn Sie
--ip=127.0.0.1versuchen?