Ipython: Erreur de socket 99 pour le bloc-notes ipython
salut
lorsque j'essaie d'ouvrir un ordinateur portable, j'obtiens une erreur de socket 99 "Impossible d'attribuer l'adresse demandée". Cela s'est produit après une mise à jour du système, bien qu'Ipython n'ait été mis à jour que de 2.1.0-62 à 2.1.0-63 (paquet SuSE), j'ai vérifié les éléments suivants sans succès :
- vérifié si le périphérique de bouclage est en cours d'exécution (c'est avec inet addr:127.0.0.1 Mask:255.0.0.0)
- vérifié avec netstat -lp si le port standard est déjà affecté (il ne l'était pas)
- exécutez un petit script de test pour démarrer le serveur Web tornado au port 8888, cela a fonctionné
- Créez un profil par défaut et exécutez à nouveau ipython
- Ipython démarré avec un hôte explicite et un port (aléatoire) (ordinateur portable ipython --init --ip='localhost' --port=49151)
- Essayé est en tant que root
- Vérifié que le pare-feu ne bloque pas
- J'ai vérifié que je suis capable d'écrire sur tmp (au cas où cela serait nécessaire)
Je ne sais donc pas quoi faire d'autre. Tout pointeur sur ce que je peux faire d'autre est apprécié.
Le message de démarrage est
tmp/> bloc-notes ipython --init --log-level=50 --ip='localhost' --port=49151 [15:46:39]
Traceback (appel le plus récent en dernier) :
Fichier "/usr/bin/ipython", ligne 5, dans
start_ipython()
Fichier "/usr/lib/python2.7/site-packages/IPython/ init .py", ligne 120, dans start_ipython
return launch_new_instance(argv=argv, _kwargs)Fichier "/usr/lib/python2.7/site-packages/IPython/config/application.py", ligne 563, dans launch_instanceapp.initialize(argv)Déposer "
erreur : [Errno 99] Impossible d'attribuer l'adresse demandée
Ma configuration système est
{'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',
'plateforme' : '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 (par défaut, 21 novembre 2013, 15:55:38) [GCC]'}
Ma version tornade est
Nom : python-tornado/Version : 3.2.1-2.1/Arch : x86_64
gluincth
Tous les 13 commentaires
Et si vous essayiez --ip=127.0.0.1 ?
minrk
le 23 juil. 2014
salut
Ça marche (j'aurais dû y penser). Je l'ai mis dans mon ipython_notebook_config.py. Je me demande pourquoi le comportement a changé...
Donc, de mon côté, je pourrais clore ce sujet. Seulement si l'on pouvait changer le message d'erreur en quelque chose de significatif qui pointe vers la solution, je garderais ce problème ouvert. Mais peut-être que ce problème est trop spécifique...
Merci beaucoup pour la réponse rapide !
gluincth
le 24 juil. 2014
Copie de l'explication du #6191 :
IPython écoute sur localhost par défaut. 127.0.0.1 devrait se comporter de la même manière, et c'est le cas dans presque tous les cas. Certains cas où cela peut être géré différemment incluent les proxys locaux et/ou les pare-feu (généralement dus à un oubli de configuration, plutôt qu'à une différence intentionnelle de comportement). Nous avons trouvé des cas où localhost fonctionne et 127 non et vice versa, il n'y a donc pas de réponse correcte sans ambiguïté pour la valeur par défaut.
Avez-vous une configuration pare-feu et/ou proxy ? Si oui, contrôlez-vous sa configuration ? Je décrirais ce comportement comme un bogue dans la configuration de votre réseau, mais vous n'êtes peut-être pas autorisé à le corriger.
minrk
le 24 juil. 2014
Merci, spécifier 127.0.0.1 a également résolu l'erreur de socket pour moi
naoko
le 17 août 2014
Si vous l'utilisez dans un serveur cloud, vous pouvez utiliser --ip=0.0.0.0 .
tigerneil
le 11 déc. 2017
Merci d'avoir maintenu ce problème, je suis en train de configurer un serveur de bloc-notes sur un serveur cloud. Et spécifier l'adresse IP d'écoute comme "0.0.0.0" a résolu ce même problème.
Leegenux
le 23 janv. 2018
Merci, j'ai eu le même problème :)
OussamaSegh
le 23 oct. 2018
merci c'est résolu !
Chichilele
le 13 déc. 2018
Pour les personnes provenant des résultats de recherche : vérifiez votre /etc/hosts pour les fautes de frappe et la configuration ipv6. localhost ne doit pointer que vers le bouclage ipv4 ( 127.0.0.1 ), pas vers ipv6 ( ::1 ). Cela peut casser d'autres choses, pas seulement Jupyter.
Par exemple, c'est faux :
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
C'est acceptable:
::1 localhost6 localhost6.localdomain6
https://github.com/codenvy/codenvy/issues/2427#issuecomment -397347888
https://bugzilla.redhat.com/show_bug.cgi?id=211800#c4
mlazowik
le 21 févr. 2019
@mlazowik Merci beaucoup ! Cela a résolu mon problème - je me demande combien d'autres ont ce même problème mais ont opté pour la solution 127.0.0.1. C'est la bonne solution (en s'assurant que la table de recherche de nom d'hôte est correcte). Dans mon cas (Arch Linux), mon /etc/hosts été "expédié" comme suit :
127.0.0.1 localhost.localdomain localhost
::1 localhost.localdomain localhost
Et je l'ai corrigé comme suit :
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
craymichael
le 3 juil. 2019
Si vous l'utilisez dans un serveur cloud, vous pouvez utiliser
--ip=0.0.0.0.
Pour moi (sur mac), seul le --ip=0.0.0.0 fonctionne avec le docker en cours d'exécution local.
0xfeedbac
le 3 sept. 2019
Dans mon cas, cela est dû au /etc/hosts pour l'adresse de bouclage ::1 dupliquée dans IPv6.
Après avoir commenté la deuxième adresse de bouclage ::1, l'erreur a disparu.
liho98
le 14 déc. 2019
@mlazowik J'ai eu le même problème avec la même solution éventuelle, mais j'ai trouvé intéressant que man /etc/hosts ait cela dans leur exemple, ce qui m'a empêché de comprendre mon problème (car une autorité présumée recommande exactement ce que vous dites est problématique):
# 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
J'ai laissé tomber le localhost de l'entrée ::1 (en gardant les deux autres) et tout va bien. J'ai également supposé que ip6 était un mot-clé ipv6 , mais peut-être que ip6-foo et foo6 sont tous les deux très bien (par exemple juste une forme de mutilation de nom contre le ipv4 équivalent) ?
jwhendy
le 7 janv. 2020
Questions connexes
alvations
·
4Commentaires
ericdill
·
3Commentaires
ghost
·
4Commentaires
ederag
·
3Commentaires
RinaldoB
·
3Commentaires
Commentaire le plus utile
Et si vous essayiez
--ip=127.0.0.1?