Что является источником и решением для “порта 9000: Соединение отказалось” от ошибки?
Я - stuggeling с port 9000: Connection refused ошибка.
Я продолжаю работать Ubuntu 14.04 и стоял перед проблемой при попытке работать Hadoop в нераспределенном режиме, как единственный процесс Java (сравнивают Hadoop 2.4.1 документации). Я пытался следовать за предложениями Wiki Hadoop на этой ошибке (hadoop/ConnectionRefused), но я не успешно выполнялся (я - новичок Ubuntu пользователь и находит, что это трудный даже к 100% понимает данные предложения). Я отправил stackoverflow вопрос, из которого я делаю вывод, что у меня есть некоторая общая проблема с port 9000 Connection.
telnet произвел:
martakarass@marta-komputer:~$ telnet localhost 9000
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
nmap производят:
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
Конфигурация Netcat:
Я пытался использовать следующую команду, чтобы вынудить 9 000 портов быть открытыми:
nc -k -l 9000
но это не работало хорошо (я все еще не смог выполнить standlone операцию, упомянутую и связанную выше).
Судя по моим результатам исследования Google, я вижу, что проблема является довольно типичной и излагает огромную борьбу специально для тех, кто не хорош в "admin-job-related проблемы". Поскольку я принадлежу тем, я прошу ответов на следующие вопросы:
Q1: Каков источник такой проблемы в целом? (Некоторые для неспециалиста вводные слова / ссылки о важных вопросах, подключенных к портам / соединения и т.д., были бы очень очень welome).
Q2: Как иметь дело с этой проблемой?
Обновление.
sudo netstat -nlp | grep :9000
возвраты ничто.
3 ответа
В конечном счете мне удалось заставить мой сервис слушать порт 9000 путем добавления к /etc/ssh/sshd_config зарегистрируйте следующую строку:
Port 9000
Я следовал за этим serverguide/openssh-server (он содержит также некоторые важные комментарии о создании копии исходного файла, перезапуская sshd серверное приложение и т.д.),
После этого я вижу:
telnet произвел:
martakarass@marta-komputer:~$ telnet localhost 9000
Trying 127.0.0.1...
Connected to localhost.
nmap производят:
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 производят:
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
TL; DR сначала, больше следующего деталей:
"Соединение, которому отказывают", является ошибкой, которую Вы получаете, когда Вы пытаетесь соединиться с сервисом на компьютер или сервер (или локально на Ваш собственный компьютер), когда упомянутый сервис или не слушает на указанном порте TCP (неправильный порт или сервис, не запущенный), или когда брандмауэр явно отклоняет соединение вместо того, чтобы игнорировать запрос (не очень общее поведение).
И теперь немного больше детали:
Это может только произойти с TCP (сервисы UDP являются sessionless), и эта ошибка действительно очень характерна для sys администраторов.
, Когда клиентское приложение соединится с сервисом TCP, оно отправит первый пакет с набором флага SYN. Если мы упрощаем, существует два возможных ответа на это:
- сервер на самом деле слушает на необходимом порте TCP и ответах с пакетом SYN-ACK для подтверждения пакета SYN, после которого клиенты разрывает пакет ACK, чтобы "подтвердить" к серверу, что SYN-ACK был получен. Это - момент, где Вы установили сеанс TCP, и когда можно начать "говорить" с сервером.
- сервер получает Ваш пакет SYN, но не слушает на требуемом порте. Соединение отклоняется с пакетом, который имеет RST (сброс) набор флага. Это - 99% времени, когда Вы получаете печально известное "соединение, которому отказывают".
, Как я фиксирую это?
ну, существует несколько вещей, которые можно проверить: Вы запрашиваете правильный порт на стороне клиента? Ваш сервис запускается? Это слушает на правильном порте?
Те три вопроса будут обычно помогать Вам решить свою проблему.
Быстрая групповая команда, которая будет вводиться в сервер (машина, которая выполняет сервис)
Проверка, что сервис слушает на ожидаемом порте
ss -nat | grep <enter port number here> | grep LISTEN
, Некоторые люди в более старых системах могли бы также использовать это
netstat -an | grep <enter port number here> | grep LISTEN
, Если Вы не видите ничего здесь, которое похоже на Ваш номер порта, Ваш сервис или не запускается или не слушающий на номере порта, который Вы определили.
Проверка, что услуга работает
service <service name> status
Попытка действительно отключает iptables:
sudo service iptables stop && sudo service ip6tables stop
Тогда перезапуск hadoop. Если это помогло Вам должными быть сделать надлежащую конфигурацию для своего брандмауэра.