Debian/Ubuntu: Name or service not known и Temporary failure in name resolution в SSH, sudo, cron и systemd

Ошибка Name or service not known в Debian и Ubuntu кажется простой только на первый взгляд. На практике она всплывает в самых разных местах: при SSH-подключении, в sudo, в заданиях cron, внутри unit-файлов systemd, в скриптах резервного копирования, деплоя и мониторинга. Часто рядом встречается и родственная формулировка Temporary failure in name resolution.

Это не «ошибка SSH» и не «поломка sudo». Это симптом того, что конкретный процесс не смог через системный резолвер преобразовать имя в адрес или, наоборот, локальное имя хоста в корректное представление. Поэтому лечить нужно не приложение, а всю цепочку разрешения имён: hostname, /etc/hosts, DNS-настройки, поведение резолвера, доступность сети и контекст запуска процесса.

В Linux за это обычно отвечает вызов getaddrinfo(). Именно он используется многими программами вместо прямой работы с DNS. Поэтому одна и та же корневая проблема может проявиться как:

• ssh: Could not resolve hostname ...: Name or service not known;
• sudo: unable to resolve host ...;
• ошибки в заданиях cron, где wget, curl, rsync или клиент БД не находят имя;
• падение systemd-сервиса, который обращается к API, БД или внутреннему hostname до готовности сети.

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

Что означают эти ошибки на практике

Несмотря на схожесть, формулировки полезно различать.

Name or service not known чаще говорит о том, что имя в текущем контексте вообще не удалось интерпретировать или найти. Это может быть несуществующий hostname, опечатка, лишний символ, ошибочная запись в конфиге, отсутствие записи в /etc/hosts или неудачное разрешение через DNS.

Temporary failure in name resolution обычно намекает на временную недоступность механизма разрешения имён. Например, DNS-сервер не отвечает, сеть ещё не поднялась, systemd-resolved не готов, в контейнере нет корректного resolv.conf, оборвался маршрут до резолвера или локальный кэширующий резолвер завис.

Если очень грубо: Name or service not known чаще похоже на «имя не найдено или задано неверно», а Temporary failure in name resolution — на «имя, возможно, нормальное, но сейчас резолвер не может его обработать».

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

Как Linux вообще разрешает имена

Когда программа вызывает getaddrinfo(), система смотрит, откуда брать ответ. Порядок источников обычно задаётся в /etc/nsswitch.conf. Для строки hosts: типичный вариант выглядит так:

hosts: files dns

На системах с systemd-resolved можно встретить и такой вариант:

hosts: files resolve [!UNAVAIL=return] dns

Дальше в игру вступают локальное имя машины, /etc/hosts, содержимое /etc/resolv.conf, работа systemd-resolved или другого сетевого менеджера и, конечно, сама сеть. Именно поэтому «не резолвится имя» не всегда означает «сломался DNS».

Например, если локальный hostname сервера не прописан в /etc/hosts, то sudo будет ругаться даже при полностью рабочем интернете. А если сервис стартует в момент, когда маршрут до DNS ещё не появился, проблема уже не в hostname, а в порядке запуска.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

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

Быстрая схема диагностики

Если нужно не читать теорию целиком, а сразу локализовать проблему, идите в таком порядке:

1. Понять, какое именно имя не разрешается.
2. Проверить локальный hostname и содержимое /etc/hosts.
3. Посмотреть, что находится в /etc/resolv.conf.
4. Проверить резолвинг через getent, resolvectl, host или dig.
5. Убедиться, что DNS-сервер достижим по сети.
6. Если проблема в systemd — проверить порядок запуска и готовность сети.
7. Если проблема в cron — проверить окружение, PATH и пользователя, от которого идёт запуск.

Ниже разберём каждый сценарий подробнее.

Случай 1: sudo пишет unable to resolve host

Классика на Debian/Ubuntu: вы меняете hostname, после чего каждый запуск sudo сопровождается сообщением вроде:

sudo: unable to resolve host server01: Name or service not known

Чаще всего причина простая: имя в /etc/hostname или вывод hostname не совпадает с записью в /etc/hosts.

Проверяем текущее имя хоста:

hostname
hostnamectl status
cat /etc/hostname

Смотрим /etc/hosts:

cat /etc/hosts

Ожидаемо вы увидите что-то в таком духе:

127.0.0.1 localhost
127.0.1.1 server01

::1 localhost ip6-localhost ip6-loopback

На Debian и Ubuntu строка с 127.0.1.1 для локального hostname — обычная практика. Если hostname равен server01, а в /etc/hosts записан старый oldname, sudo начинает жаловаться.

Исправление простое: привести /etc/hostname, вывод hostnamectl и /etc/hosts к одному значению. После правки удобно проверить:

getent hosts $(hostname)

Если команда ничего не возвращает, локальное имя всё ещё не резолвится через NSS.

Почему sudo вообще делает резолвинг

sudo нередко пытается определить локальное имя хоста для логов, политики доступа и корректного представления системы. Поэтому проблема проявляется даже без внешних сетевых обращений. Это частый ложный след: администратор начинает проверять интернет, хотя сломан лишь локальный mapping hostname.

Случай 2: SSH не может разрешить хост

Типичное сообщение выглядит так:

ssh: Could not resolve hostname db.internal: Name or service not known

Здесь важно сразу отделить два случая.

• Вы подключаетесь к удалённому хосту, и клиентская машина не может разрешить его имя.
• Вы уже подключились, а на удалённой стороне внутри сессии ломается разрешение имён для других команд.

В первом случае проблема на клиенте. Во втором — на сервере.

Для начала проверьте имя без SSH:

getent ahosts db.internal
getent hosts db.internal

Если ответа нет, проверьте, не ошиблись ли вы в имени, не нужен ли search-домен и что реально прописано в SSH-конфиге:

grep -R "Host\|Hostname" /etc/ssh/ssh_config ~/.ssh/config

Нередко проблема в алиасе: администратор пишет ssh prod-db, ожидая, что alias описан в ~/.ssh/config, но в реальности блок Host отсутствует, повреждён или не читается из-за неверных прав.

Если имя должно резолвиться локально, добавьте корректную запись в /etc/hosts или исправьте DNS-зону. Если это внутреннее имя, важно понимать, откуда клиент вообще должен о нём узнать: из корпоративного DNS, VPN, локального hosts-файла или search-домена.

Полезная проверка для SSH

Команда ниже показывает итоговую конфигурацию после применения алиасов и include-файлов:

ssh -G db.internal

Так можно быстро увидеть, во что реально превращается Hostname, какой порт используется и нет ли ошибки в имени ещё до установления соединения.

Случай 3: Temporary failure in name resolution в cron

cron часто становится источником загадок, потому что задача вручную работает, а по расписанию — нет. На деле тут обычно смешиваются две вещи: урезанное окружение и сетевые или DNS-проблемы в момент запуска.

Пример: скрипт с curl api.local отрабатывает из shell, но ночью в cron пишет Temporary failure in name resolution. Что проверить:

• какой пользователь запускает задачу;
• есть ли у него доступ к нужным файлам и переменным окружения;
• используется ли FQDN вместо короткого имени;
• поднята ли сеть и доступен ли DNS в момент старта;
• не подменяется ли resolv.conf другой службой;
• не зависит ли скрипт от VPN, которая ночью переподключается.

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

Например, временно замените строку crontab на явный диагностический запуск:

* * * * * /usr/bin/date >> /tmp/cron-debug.log 2>&1
* * * * * /usr/bin/env >> /tmp/cron-debug.log 2>&1
* * * * * /usr/bin/getent hosts example.com >> /tmp/cron-debug.log 2>&1

Так вы увидите, есть ли у cron-задачи вообще рабочий резолвинг в тот момент, когда она исполняется.

Если внутри задания используются короткие имена вроде db01 вместо db01.example.internal, проблема может быть в отсутствии нужного search-домена в resolv.conf. На серверах лучше избегать зависимости от search-суффиксов и использовать полные доменные имена.

Если вы как раз наводите порядок в расписаниях и фоновых задачах, пригодится материал про разницу между cron, crontab и systemd timers.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Случай 4: systemd-сервис стартует раньше DNS или сети

Очень частый сценарий: приложение запускается через systemd, при старте обращается к API, Redis, PostgreSQL, SMTP или внешнему webhook, получает Temporary failure in name resolution и падает. Вручную после загрузки всё работает.

Это почти всегда говорит о порядке запуска. Сервис стартует тогда, когда линк уже поднят, но DNS ещё не готов, маршрут не появился, VPN не подключилась или systemd-resolved ещё не обслуживает запросы.

Смотрите unit:

systemctl cat myapp.service

Если сервис действительно зависит от готовой сети, в unit могут понадобиться:

[Unit]
Wants=network-online.target
After=network-online.target systemd-resolved.service

Но здесь есть тонкость: network.target и network-online.target — не одно и то же. Первый означает лишь факт инициализации сетевого стека, а не доступность DNS и маршрутов. Второй ближе к «сеть реально готова», хотя и это зависит от используемого network manager.

После правки нужно проверить, есть ли в системе сервис, который обеспечивает ожидание готовности сети, например systemd-networkd-wait-online или эквивалент от NetworkManager. Иначе зависимость от network-online.target останется декларативной.

Для диагностики особенно полезны:

journalctl -u myapp.service -b
systemctl status myapp.service
systemd-analyze critical-chain myapp.service

Если сервис должен переживать кратковременные DNS-сбои, добавьте разумный рестарт и задержку между попытками:

[Service]
Restart=on-failure
RestartSec=5s

Это не лечит корень проблемы, но делает сервис устойчивее к реальным условиям запуска. Если нужна более глубокая автоматизация, посмотрите и разбор systemd timers для серверных задач.

Проверяем /etc/hosts: локальная база имён, которую часто забывают

/etc/hosts особенно важен для локального hostname, внутренних служебных имён и аварийных статических записей. Ошибки здесь могут быть очень неприятными: неправильное имя, лишний символ, отсутствие записи для текущего hostname, дубли, запись FQDN на loopback там, где нужен реальный адрес.

Проверьте файл внимательно:

nl -ba /etc/hosts

Обратите внимание на:

• совпадает ли имя из hostname с записью в файле;
• нет ли двух разных строк для одного и того же имени;
• не указывает ли нужное сетевое имя на 127.0.0.1 по ошибке;
• нет ли опечаток и скрытых символов после редактирования.

Для проверки используйте не только ping, но и getent. Именно getent идёт через NSS и показывает поведение ближе к тому, как его видят реальные приложения.

getent hosts localhost
getent hosts $(hostname)
getent hosts your-name-here

Проверяем /etc/resolv.conf и кто им управляет

На Debian и Ubuntu /etc/resolv.conf может быть обычным файлом, а может быть символической ссылкой, которую генерируют systemd-resolved, resolvconf, NetworkManager или netplan. Частая ошибка — вручную править файл, который через минуту будет перезаписан.

Сначала смотрим, что это вообще такое:

ls -l /etc/resolv.conf
cat /etc/resolv.conf

Что настораживает:

• в файле нет ни одного nameserver;
• указан локальный stub-адрес, но соответствующий сервис не работает;
• записан DNS, до которого нет маршрута;
• ненужные или вредные search-домены;
• следы ручных правок, которые конфликтуют с сетевым менеджером.

Если используется systemd-resolved, полезно проверить его состояние:

systemctl status systemd-resolved
resolvectl status
resolvectl query example.com

Если resolv.conf указывает на 127.0.0.53, а systemd-resolved отключён или упал, вы как раз и получите массовые Temporary failure in name resolution.

Проверяем DNS не «вообще», а именно так, как его видит система

Утилиты типа dig полезны, но они не всегда отражают поведение обычных приложений. dig опрашивает DNS напрямую, а программы используют системный резолвер и NSS. Поэтому правильная последовательность такая:

getent hosts example.com
getent ahosts example.com
resolvectl query example.com
host example.com

Если dig работает, а getent нет, проблема может быть не в DNS-сервере, а в NSS, nsswitch.conf, локальном резолвере или окружении процесса.

Также проверьте доступность DNS-сервера по сети. Например, если в resolv.conf указан внутренний резолвер, а интерфейс с маршрутом ещё не поднят, запросы будут зависать или падать.

ip address
ip route
ss -ulpn | grep ':53 '
ping -c 1 192.0.2.53

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

Когда виноват nsswitch.conf

Файл /etc/nsswitch.conf трогают нечасто, но если его уже меняли, он может ломать логику разрешения. Проверьте строку hosts::

grep '^hosts:' /etc/nsswitch.conf

Нормальные варианты зависят от системы, но смысл должен быть понятным: сначала локальные файлы, затем DNS или resolved. Если там экзотическая последовательность, отсутствует dns или есть неверные модули NSS, приложения начнут вести себя странно.

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

Отдельно про hostname, FQDN и короткие имена

Во многих инфраструктурах часть проблем рождается из-за смешения коротких имён и FQDN. Скрипт использует db01, а DNS знает только db01.example.internal. Или наоборот: локальный hostname машины — короткий, а в /etc/hosts прописан только FQDN без алиаса.

Практическое правило простое:

• для автоматизации, systemd, cron и конфигов сервисов используйте FQDN, если имя не строго локальное;
• локальный hostname сервера должен корректно резолвиться хотя бы через /etc/hosts;
• не надейтесь на search-домены там, где важна предсказуемость.

Если вы поднимаете новый проект и вам нужно не только окружение, но и регистрация доменов, заранее продумайте схему FQDN и внутреннего именования — это реально экономит время на дальнейшей эксплуатации.

Как понять, в какой точке ломается резолвинг

Когда проблема плавающая, полезно сравнить поведение в разных контекстах: интерактивный shell, root через sudo, cron и systemd unit. Один и тот же сервер может вести себя по-разному только потому, что процессы стартуют в разное время и с разным окружением.

Минимальный диагностический набор:

hostname
hostname -f
cat /etc/hostname
cat /etc/hosts
cat /etc/resolv.conf
grep '^hosts:' /etc/nsswitch.conf
getent hosts $(hostname)
getent hosts example.com
resolvectl status
journalctl -b --no-pager | grep -Ei 'resolve|dns|network'

Если это systemd-сервис, добавьте временный ExecStartPre с диагностикой или вынесите проверки в отдельный shell-скрипт, который пишет лог. Если это cron, направьте stdout и stderr в файл и печатайте результат getent прямо перед основной командой.

Типовые причины по приоритету

На практике чаще всего встречаются такие источники проблемы:

1. Hostname изменили, а /etc/hosts не поправили.
2. /etc/resolv.conf пустой, повреждён или перезаписывается не тем сервисом.
3. systemd-resolved настроен, но не работает.
4. Сервис стартует раньше реальной готовности сети.
5. В cron используются короткие имена, завязанные на search-домены.
6. Опечатка в hostname или alias в SSH-конфиге.
7. DNS-сервер недоступен по сети или изменился маршрут.
8. Повреждён или нестандартно настроен /etc/nsswitch.conf.

Практический мини-алгоритм исправления без лишней магии

Если нужно быстро вернуть систему в рабочее состояние, не распыляясь на десятки гипотез, действуйте так:

1. Проверьте, какое имя не разрешается.
2. Если это локальный hostname — сразу сверяйте hostname, /etc/hostname и /etc/hosts.
3. Если это внешний или внутренний домен — проверяйте /etc/resolv.conf и доступность DNS-сервера.
4. Сравните результат getent и dig. Это быстро отделяет проблему NSS от проблемы DNS.
5. Для systemd проверьте зависимости After= и Wants=, а также логи загрузки.
6. Для cron уберите зависимость от коротких имён и неявного окружения.
7. После исправления тестируйте именно тем способом, которым проблема проявлялась изначально.

Главная ошибка при таких инцидентах — исправить DNS «в целом», но не проверить исходный сценарий. Если ломался cron, тестируйте из cron. Если падал unit, перезапускайте unit. Если ругался sudo, проверяйте локальный hostname.

Что делать, чтобы ошибка не вернулась

• Используйте FQDN в автоматизации и сервисных конфигах.
• Не редактируйте /etc/resolv.conf вслепую — сначала выясните, кто им управляет.
• После смены hostname всегда проверяйте /etc/hosts.
• Для systemd-сервисов, зависящих от сети, задавайте корректные зависимости и перезапуск по сбою.
• Для cron-задач задавайте явные пути, логирование и минимальные самопроверки DNS перед основной логикой.
• Держите под рукой короткий runbook с командами getent, resolvectl, hostnamectl и journalctl.

Итог

Ошибки Name or service not known и Temporary failure in name resolution в Debian/Ubuntu почти всегда сводятся к одной из четырёх зон: локальное имя хоста, /etc/hosts, DNS-конфигурация через resolv.conf или systemd-resolved, либо неверный контекст запуска процесса в cron и systemd.

Если не гадать, а идти от имени, которое не резолвится, к источнику данных и затем к сети, причина находится довольно быстро. И да, лучший первый тест в таких историях — не ping, а getent hosts имя: он гораздо ближе к тому, как проблему видят реальные приложения через getaddrinfo().