Да 127.0.0.11 — это локальный экземпляр DNS-сервера, который, вероятно, работает на виртуальной машине Hortonworks. Он прослушивает порт 53. Вы знаете это по этой строке в ответе dig
:
;; SERVER: 127.0.0.11#53(127.0.0.11)
Большинство людей с удивлением узнают, что существует нечто большее, чем просто хорошо известный IP-адрес 127.0.0.1 для локального хоста. На самом деле это /8
с точки зрения адресного пространства :
$ ip a l lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
Таким образом, такие адреса, как 127.0.0.2 и т. д., — это все адреса, которые система может использовать внутри себя для всего, что считается необходимым. В этом случае DNS-сервер привязан к порту 53 на этом IP-адресе.
Вы можете подтвердить поиск с помощью команды ss
:
$ ss -ltpn '( sport = :53 )' | less
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 5 *:53 *:* users:(("dnsmasq",pid=24086,fd=7))
LISTEN 0 5 :::53 :::* users:(("dnsmasq",pid=24086,fd=9))
(END)
В приведенном выше примере мы видим, что dnsmasq
, то есть PID 24086, — это процесс, прослушивающий порт 53.
Как только мы узнаем PID, мы можем начать смотреть на него, чтобы выяснить, какие файлы он использует:
$ lsof -p 24086 | grep -E '/etc|/var'
dnsmasq 24086 dnsmasq 3u REG 179,2 1103 128324 /etc/pihole/dhcp.leases
dnsmasq 24086 dnsmasq 13w REG 179,2 3201111 20530 /var/log/pihole.log
ПРИМЕЧАНИЕ.:Имейте в виду, что большинство сервисных демонов обычно открывают свои файлы конфигурации, читают их, а затем закрывают, поэтому не пугайтесь, если мы не увидим никаких файлов конфигурации в приведенном выше выводе.
Из приведенного выше вы можете следовать файлу журнала, чтобы выяснить, как перенастроить любой DNS-сервер, с которым вы имеете дело.
У меня аналогичные проблемы с клавиатурой с другим (и более длинным )стеком коммуникационных программ, например получение невидимых символов или редких кодов, но я думаю, что они вызваны тем, что я случайно нажал комбинацию клавиш, которая меняет функции терминала.
У меня действительно нет времени, как вы говорите, копаться в определениях терминов и искать, какие клавиши могут спровоцировать изменение, например, если нажатие a+b+c во время яростного сеанса печати может привести к тому, что клавиатура отправит Команда XOFF ^S на удаленный терминал, которая прекращает отправку вывода или что-то в этом роде. Нам нужна программа захвата ключей для сохранения нажатых клавиш и еще одна на пульте дистанционного управления для получения полученных для устранения неполадок. Кроме того, поскольку задействовано несколько программ, трудно обвинить ту или иную из них.
В то же время, иногда команды stty sane
или reset
в терминале решали эту проблему для меня (из-за этих случаев я думаю, что это непонятная команда ключевого термина, неосознанно вызывающая проблему ); в других случаях мне приходилось перезапускать оболочку, как это делаете вы, или даже переподключать часть стека.
Попробуйте использовать команду lsof, предложенную roaima в комментарии к вашему вопросу. Вот пример, который показывает, как bash и команда lsof имеют открытый дескриптор файла (FD )0 (=stdin ), но ни одна из них не читает из него во время выполнения команды. Вы должны искать другие процессы, у которых открыт файловый дескриптор 0. Убивайте их по одному, пока проблема не исчезнет. Очевидно, не bash, если вы не видите, что FD 0 открывается несколько раз bash.
$ lsof /dev/pts/8
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
bash 15190 thisusr 0u CHR 136,8 0t0 11 /dev/pts/8
bash 15190 thisusr 1u CHR 136,8 0t0 11 /dev/pts/8
bash 15190 thisusr 2u CHR 136,8 0t0 11 /dev/pts/8
bash 15190 thisusr 255u CHR 136,8 0t0 11 /dev/pts/8
lsof 19576 thisusr 0u CHR 136,8 0t0 11 /dev/pts/8
lsof 19576 thisusr 1u CHR 136,8 0t0 11 /dev/pts/8
lsof 19576 thisusr 2u CHR 136,8 0t0 11 /dev/pts/8