sudo systemctl долго реагирует на команду если в resolv.conf некорректный ip

Порт 53 занимает systemd-resolvd, пробовал его отключить, не помогает.

А как это поможет, если в /etc/resolv.conf ты указываешь не

nameserver 127.0.0.1

А IP адрес другого DNS сервера?

Пропиши в конфигурационном файле systemd-resolved адрес нужного DNS, а в /etc/resolv.conf укажи 127.0.0.1

Попробуй указать корректный.

Этот девайс будет работать где нет интернета, к примеру. Там что корректный что некорректный - та же фигня. Это выяснилось, кстати, именно там где нет инета, провел инет случайно приспичило, стало реагировать на команды нормально, потом убрал DNS адрес и начались тормоза. При этом инет работает по IP.

При этом инет работает по IP.

Потому, что не требует преобразования DNS имени в IP адрес для подключения.

Этот девайс будет работать где нет интернета, к примеру. Там что корректный что некорректный - та же фигня.

Ну значит попробуй убрать вообще, но в целом нужно прописать 127.0.0.1.

Пытаюсь понять почему это стало влиять на реакцию команд в ssh консоли.

В том то и дело почему кривой IP в DNS вдруг влияет на реакцию выполнения команд в ssh консоли.

Вылечилось если прописать nameserver 127.0.0.1

Настройки DNS клиента в linux такие: 3 попытки отправить DNS запрос на указанный DNS сервер, если он не отвечает после первой попытки, вообще не отвечает, - ждём 5 секунд, делаем следующую попытку, потом третью и если после трёх попыток запроса ответ не приходит - идём к следующему DNS серверу.

Почитай man resolv.conf.

Если он один - прекращаем попытки.

Это всё при использовании DNS имён.

Пропиши 127.0.0.1 или поменяй приоритет разрешения имён или вообще убери DNS в файле /etc/nsswitch.conf, в параметре hosts:.

Молодец, подумал и сделал, хвалю.

Вопрос же в другом, как влияет нажатие ЕНТЕР в консоли SSH на реакцию исполнения команды от корректности IP в resolv.conf.

На самом деле локалхост в DNS не помог, показалось.

Приведи пример команды.

Ну вот не верю, что допустим команда ls как-то не так работает.

Проверил на своём Debian, прописал в /etc/resolv.conf IP адрес, отсутствующий в сети и аналогично указывал адрес, который есть, но там нет DNS сервера.

Команда ls как работала так и работает одинаково, без задержек.

примеры команд в топике.

Ну тебя взломали видимо и подсунули exploit.

Смотри через strace что происходит.

Покажи содержимое /etc/nsswitch.conf.

Что в этот момент в journalctl -xe?

Отправки истории команд на внешний syslog сервер случаем в bash не настроена? Может там указан адрес сервера по доменному имени.

У тебя Arch?

При чем здесь взлом?! facepalm, этот девайс без интернета работает вообще, онлайн случайно пришлось подключить и ву-а-ля команды стали выполняться шустрее. А потом и до DNS дошло дело, route прописан же на шлюз. Инет есть, но команды продолжают тормозить пока DNS кривой.

armbian

Покажи содержимое /etc/nsswitch.conf.

Оно стандартное и другом девайсе такое же где нет тормозни с исполнением команд оффлайн вообще.

 #
 # Example configuration of GNU Name Service Switch functionality.
 # If you have the `glibc-doc-reference' and `info' packages installed, try:
 # `info libc "Name Service Switch"' for information about this file.

 passwd:         compat systemd
 group:          compat systemd
 shadow:         compat
 gshadow:        files

 hosts:          files mymachines dns myhostname
 networks:       files

 protocols:      db files
 services:       db files
 ethers:         db files
 rpc:            db files

 netgroup:       nis

Я просто шучу над тобой.

Пишешь о чём-то, а команды не приводишь.

Если у тебя есть задержка отклика в SSH соединении от нажатия Enter, то возможно просто перегружен канал связи.

Я печатаю почти в слепую (быстро) и могу сразу оценить загрузку канала, если набираемый текст медленно в SSH клиенте прорисовывается.

Следовательно проблема со связью.

Если ты печатаешь медленно, набираешь одним пальцем команды, то ты не увидишь и возможно ты считаешь долгий отклик нажатия Enter проблемой с DNS, а она просто из-за нагрузки на сеть.

Либо процессор твоего ARM устройства перегружен или память.

Проверь это.

В консоли вывод команд htop, free -h, top. Или процессор перегрет и тротлит.

Нагрузка ввода / вывода на SD карту тоже может быть причиной, каждая команда в Linux - это отдельная команда и она считывается с накопителя. Смотри iotop.

В общем, я считаю, что твоя гипотеза с DNS попроству не верна, а проблема на уровне канала или загрузки / перегрева оборудования.

Ага, ещё и докеры крутишь на нём.

Взял другую ОС, x64, тоже армбиан и там тот же цирк. Но на обе ОС установлен специфичный софт, хотя и стопнут, но подтянул оч много пакетов официальных.

канал связи рядом свитч.

У тебя armbian, я проверил на Debian, указал неверный DNS сервер - проблем нет.

Вывода strace или логов journalctl -xe от тебя не увидел.

нагрузки нет, вызов sudo htop тоже тормозит потом отображает нет никакой нагрузки. Все что можно стопнуто. И так до тех пор пока не появится онлайн если роут не прописан или ДНС не исправится на корректный.

Видимо надо брать чистый образ и на нем сразу все смотреть, а потом накатывать свой специфичный софт и его пакеты какие потребуются. :(

journalctl -xe

там нет ничего и тоже сама команда тормозит пока выполнится.

/etc/resolv.conf

этот файл можно вообще удалить - сустемд он не нужен, оно его будет само создавать для обратной совместимости

Еще симптом: под sudo команды тормозят, без sudo нет (при кривом DNS).

https://unix.stackexchange.com/questions/401008/sudo-command-hangs

The problem can reproduced when the hostname is changed , edit your /etc/hosts by adding the output of echo $HOSTNAME after 127.0.0.1:

echo 127.0.0.1 localhost $(hostname) >> /etc/hosts

Убери из настройки хостов в /etc/nsswitch.conf для теста упоминание DNS и проверь как работает.

Вот я примерно в том же ключе и думаю.

Только более правильно всё же будет

echo 127.0.0.1 $(hostname -f) $(hostname) localhost >> /etc/hosts

Чувак! Сработало, hostname меняли, а там не прописано было почему-то.

меняли так

sudo hostnamectl set-hostname NEWHOSTNAME

меняет в /etc/hostname, но не в /etc/hosts

и теперь если нет инета или ДНС кривой то под sudo начинается цирк.

Всем спасибо, по sudo hangs тоже гуглил, не успел прочитать найденное, здесь уже прочитал

Вместо того чтобы менять /etc/hosts, лучше настроить NSS правильно:

hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns

этот файл можно вообще удалить - сустемд он не нужен, оно его будет само создавать для обратной совместимости

Нельзя. Он должен быть симлинком на /run/systemd/resolve/stub-resolv.conf.

Если в файле sudo nano /etc/nsswitch.conf в строке hosts: files mymachines dns myhostname убрать слово dns то тогда и при кривом dns команды под sudo не подвисают больше, при условии что имя хоста так же кривое в /etc/hosts

hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns Тогда то же начинает работать нормально.

Т.е. если поменять имя хоста командой hostnamectl не касаясь hosts, и поправить строку nss, то тоже работает.

В итоге остается последний вопрос после изменения имени хоста и больше никуда не лазить и при отсутствии инторнета: Why is internet connectivity required for sudo?

нет, спасибо, не сижу под рутом, только под юзером, уже понаступал на грабли с этим и лечил других когда те под рутом ломали систему (скажем так приводили в странное состояние, хотя и рабочее, как раз из-за путаницы владельцев и прав на файлы, программы и пр.)

Why is internet connectivity required for sudo?

Как мы только что выяснили, дело не в «отсутствии инторнета», а в том, что sudo лезет в DNS, чтобы преобразовать имя локального хоста в его адрес (или наоборот). А DNS, точнее NSS, в свою очередь был настроен так, чтобы требовать «инторнет» даже в случаях, когда можно было без этого обойтись.

Зачем — ну, навскидку, в sudoers есть возможность настраивать политики, ограниченные конкретными хостами (или адресами). Ещё там есть логирование запросов, опять же, потенциально включающее FQDN. И то, и то, если включено на конкретной машине, предполагает какие-то запросы к DNS.

как раз из-за путаницы владельцев и прав на файлы, программы и пр.)

Это как раз типичный результат использования sudo, когда глупый юзер плохо понимает что вообще происходит с правами.

нет, спасибо, не сижу под рутом

Не надо «сидеть под рутом». Пользуйся компом под юзером - безо всяких sudo. А под рутом - администрируй его. Это совершенно разные дела и они не должны пересекаться. Руту нечего делать в /home а у юзера нет прав что бы то ни было редактировать за пределами /home.

Сколько отмаз, ну зачем так делать? Именно так - sudo лезет в инет, хотя делать этого не должен. Утилита вредная и писали её дилетанты - латентные виндузятники.

В какой «инет»? Он ресолвит имя хоста, никакой «инет» и даже ДНС для этого не нужны, достаточно вменяемого /etc/hosts, который всё равно должен быть в системе. Недавно, вон, в mc находили похожий косяк — тормозил при открытии, если имя хоста сресолвить не мог.

Да чо мелочиться, сразу уж telinit 1, когда надо права у файла поменять, ога.

Это всё отмазы и они не меняют фактов - sudo может слать неожиданные сетевые запросы в некоторых обстоятельствах и лагать в ожидании ответа от них. Впрочем, возможно проблема сидит чуть глубже (в общелинуксовых традициях которые допускают лезть в инет чтоб узнать имя локального хоста, в нормальных системах оно берётся из sysctl безо всякой юзерспейсной чуши - какого-то парсинга файлов или, ещё хуже, отправок запросов), но это никак не извиняет разработчиков софта, позиционируемого как инструмент безопасности - они то должны были об этом подумать.

Не неси чушь. Есть аккаунт системного администратора, а есть аккаунт пользователя. Путать их - виндузятная привычка, и sudo её поддерживает.

Ну ничего, сейчас run0 приедет, за пару лет админы научатся вменяемо писать к polkit-у правила, причешем юзабилити и можно будет вредную утилиту выкинуть на свалку истории :>

Имя локального хоста можно узнать системным вызовом, если ты уже заранее знаешь, что тебе нужно имя локального хоста. Надо полагать, что в sudo это всё-таки часть какого-то более обобщённого механизма.

А может, у ТСа в sudoers написано «127.0.0.1»? И sudo послушно лезет проверять, что такое 127.0.0.1.

Народ заходил под рутом и сидел и делал все дела в папке юзера, потом приходил юзер и в его папке цирк и "тебе это нельзя"с его же файлами или с файлами настроек вызванных программ, у которых уже стал рут-владельцем.

И это не говоря про что заходят рутом и там выполняют команды которые не знают толком что делают (накопипастят из инетов), а потом эти команды коцают что-нибудь в ОС, и после ребута девайс помирает.

Насчет сидеть под юзерам и трогать sudo, что даже sudo nano /etc/network/interfaces или sudo systemctl нельзя делать, а надо уходить под рута для этого. Нонсенс. :)