web-dev-qa-db-fra.com

Qu'est-ce qu'une origine et une solution pour l'erreur "port 9000: Connexion refusée"?

Je suis bloqué avec l'erreur port 9000: Connection refused.

Je travaille sur Ubuntu 14.04 et je suis confronté au problème lorsque j'essaie d'exécuter Hadoop en mode non distribué, en tant que processus unique Java (comparer documentation Hadoop 2.4.1). ). J'ai essayé de suivre les suggestions de Hadoop Wiki sur cette erreur ( hadoop/ConnectionRefused ) mais je n'ai pas réussi (je suis un utilisateur débutant Ubuntu et j'ai du mal à comprendre à 100% les suggestions données. ). J'ai posté ne question de stackoverflow d'où je conclus que j'ai un problème général avec port 9000 Connection.

telnet sortie:

martakarass@marta-komputer:~$ telnet localhost 9000
Trying 127.0.0.1...
telnet: Unable to connect to remote Host: Connection refused

nmap sortie:

martakarass@marta-komputer:~$ nmap localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2015-04-27 11:09 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00022s latency).
Not shown: 995 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
139/tcp open  netbios-ssn
445/tcp open  Microsoft-ds
631/tcp open  ipp
902/tcp open  iss-realsecure

Nmap done: 1 IP address (1 Host up) scanned in 0.08 seconds

Configuration Netcat :

J'ai essayé d'utiliser la commande suivante pour forcer le port 9000 à être ouvert:

nc -k -l 9000

mais cela n'a pas bien fonctionné (je ne pouvais toujours pas effectuer l'opération autonome mentionnée et liée ci-dessus).

À en juger par les résultats de mes recherches sur Google, je constate que le problème est assez courant et pose un énorme problème, en particulier pour ceux qui ne maîtrisent pas bien les "problèmes liés aux tâches administratives". Comme je fais partie de ceux-ci, je demande avec bonté des réponses aux questions suivantes:

  • Q1 : Quelle est l'origine d'un tel problème en général? (Quelques mots pour un profane introductifs/références sur les problèmes de base liés aux ports/connexions, etc. seraient très appréciables).

  • Q2 : Comment traiter ce problème?

Mise à jour.

Sudo netstat -nlp | grep :9000

ne renvoie rien.

1
Marta Karas

Finalement, j'ai réussi à faire mon service écoute le port 9000 en ajoutant au fichier /etc/ssh/sshd_config la ligne suivante:

Port 9000

J'ai suivi ceci serverguide/openssh-server (il contient également quelques remarques importantes sur la copie du fichier d'origine, le redémarrage de l'application serveur sshd, etc.)

Après cela, je peux voir:

telnet sortie:

martakarass@marta-komputer:~$ telnet localhost 9000
Trying 127.0.0.1...
Connected to localhost.

nmap sortie:

martakarass@marta-komputer:~$ nmap localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2015-05-01 18:28 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00023s latency).
Not shown: 994 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
139/tcp  open  netbios-ssn
445/tcp  open  Microsoft-ds
631/tcp  open  ipp
902/tcp  open  iss-realsecure
9000/tcp open  cslistener

Nmap done: 1 IP address (1 Host up) scanned in 0.05 seconds

netstat sortie:

martakarass@marta-komputer:~$ Sudo netstat -nlp | grep :9000
tcp        0      0 0.0.0.0:9000            0.0.0.0:*               LISTEN      16397/sshd      
tcp6       0      0 :::9000                 :::*                    LISTEN      16397/sshd 
0
Marta Karas

TL; DR en premier, plus de détails après:

"Connexion refusée" est l'erreur que vous obtenez lorsque vous essayez de vous connecter à un service sur un ordinateur ou un serveur (ou localement sur votre propre ordinateur) lorsque ledit service n'écoute pas sur le port spécifié TCP ( mauvais service ou service non démarré), ou lorsqu'un pare-feu refuse explicitement une connexion au lieu d’ignorer la demande (comportement peu courant).

Et maintenant un peu plus en détail:

Cela ne peut se produire qu'avec TCP (les services UDP sont sans session) et cette erreur est en effet très commune pour les administrateurs système.

Lorsqu'une application cliente se connecte à un service TCP, elle envoie un premier paquet avec l'indicateur SYN défini. Si nous simplifions, il y a deux réponses possibles à cela:

  • Le serveur écoute actuellement sur le port TCP requis et répond avec un paquet SYN-ACK pour accuser réception du paquet SYN, après quoi les clients envoient un paquet ACK pour "confirmer" au serveur que le SYN-ACK était reçu. C'est le moment où vous avez établi une session TCP et où vous pouvez commencer à "parler" avec le serveur.
  • Le serveur reçoit votre paquet SYN, mais n'écoute pas sur le port demandé. La connexion est rejetée avec un paquet pour lequel l'indicateur RST (réinitialisation) est défini. C'est 99% du temps où vous obtenez la fameuse "connexion refusée".

Comment puis-je résoudre ce problème?

Vous pouvez vérifier quelques points: interrogez-vous le bon port côté client? Votre service est-il commencé? Est-ce qu'il écoute sur le bon port?

Ces trois questions vous aideront généralement à résoudre votre problème.

Commande générique rapide à entrer sur le serveur (la machine qui exécute le service)

Vérifier que le service écoute sur le port attendu

ss -nat | grep <enter port number here> | grep LISTEN

Certaines personnes sur des systèmes plus anciens peuvent également utiliser cette

netstat -an | grep <enter port number here> | grep LISTEN

Si vous ne voyez rien ici qui ressemble à votre numéro de port, votre service n'est pas démarré ou n'écoute pas le numéro de port que vous avez spécifié.

Vérifier que le service est en cours d'exécution

service <service name> status
1
Marc-Olivier Barre

Essayez de désactiver iptables:

Sudo service iptables stop && Sudo service ip6tables stop

Puis redémarrez hadoop. Si cela vous aide, vous devez configurer correctement votre pare-feu.

1
UNIm95