Ubuntu Ubuntu Linux

Ubuntu Linux: systemd показывает active, но приложение не отвечает

  • Обновлено
  • Чтение ≈ 3 минуты
  • Нужны права администратора

Краткий ответ

В Ubuntu systemctl status показывает active (running), но страница или API приложения не отвечает. Это не противоречие: systemd знает о процессе, однако не гарантирует готовность сетевого порта, правильную маршрутизацию и работоспособность бизнес-функции.

В этой статье
  1. Что означает проблема и кому подходит инструкция
  2. Возможные причины и отличительные признаки
  3. Диагностика и пошаговое устранение
  4. Как убедиться, что неисправность устранена
  5. Если результат не получен

#Что означает проблема и кому подходит инструкция

В Ubuntu systemctl status показывает active (running), но страница или API приложения не отвечает. Это не противоречие: systemd знает о процессе, однако не гарантирует готовность сетевого порта, правильную маршрутизацию и работоспособность бизнес-функции.

#Возможные причины и отличительные признаки

Возможная причинаКак узнатьЧто делать
Процесс не слушает нужный адрес/портПриложение запущено, но слушает только 127.0.0.1 или другой порт.ss не показывает ожидаемую пару адрес:порт.Проверить конфигурацию прослушивания.
Приложение зависло или не прошло проверку готовностиПроцесс жив, но не отвечает на запросы или ждёт базу данных.Тайм-аут curl при живом PID, журнал зависимостей содержит ошибки.Проверить логи и реальные зависимости, не делать бесконечные рестарты.
Отвечает локально, но не снаружиМаршрут, firewall или обратный прокси не пропускают запрос.localhost работает, удалённый клиент — нет.Диагностировать сеть и промежуточный сервис.

#Диагностика и пошаговое устранение

  1. 1. Установите ожидаемую точку доступаОткройте Терминал Ubuntu на сервере. Запишите точный URL, порт и имя службы из конфигурации приложения; не предполагайте стандартный 80 или 443. Через systemctl show проверьте PID и состояние. Типы Type=simple и notify по-разному сообщают о готовности; active не означает успешный HTTP.
    Linux · Терминал (Bash)Команда
    Подставьте действительное имя, не выводите конфиденциальное окружение.
    systemctl status ИМЯ.service --no-pager
    systemctl show ИМЯ.service -p MainPID -p Type -p ExecStart
  1. 2. Проверьте, существует ли слушающий портС помощью ss -ltnp найдите нужный TCP-порт и адрес. Если процесс слушает только 127.0.0.1, внешние клиенты не смогут подключиться прямо к нему; это нормально при обратном прокси. Для UNIX-сокетов используйте ss -xlpn и проверьте его права.
  2. Администратор позволяет увидеть владеющий процесс; не изменяет сеть
    Linux · Терминал (Bash)КомандаНужен sudo
    Администратор позволяет увидеть владеющий процесс; не изменяет сеть.
    sudo ss -ltnp
    sudo ss -xlpn
  1. 3. Отправьте безопасный локальный запросЕсли приложение HTTP, выполните curl -v --max-time 10 http://127.0.0.1:ПОРТ/ПУТЬ, подставив порт и безопасный диагностический путь (например, документированную /health, если она существует). Не считайте 404 признаком ошибки сервиса целиком: запрошенный путь может не существовать. Для HTTPS используйте https и проверку сертификата; не добавляйте -k как постоянное решение.
    Linux · Терминал (Bash)Команда
    Только безопасный GET; не вызывайте адреса, изменяющие данные. Заполнители заменить.
    curl -v --max-time 10 http://127.0.0.1:ПОРТ/ПУТЬ
  1. 4. Прочитайте последние ошибки приложения и зависимостейjournalctl -u поможет найти ошибку базы, файлов, параметров запуска, исчерпания соединений или памяти. Сопоставьте timestamp со своим пробным запросом. Для приложения с отдельными log-файлами читайте только конкретный лог, не публикуя личные данные.
    Linux · Терминал (Bash)Команда
    Только чтение, в журналах могут быть токены.
    journalctl -u ИМЯ.service -b --no-pager -n 120
    systemctl --failed --no-pager
  1. 5. Сравните локальный и внешний путь запросаЕсли локально ответ есть, но с другого устройства нет, проверьте DNS, адрес прослушивания, маршрут и настройки обратного прокси. sudo ufw status verbose показывает локальные правила при установленном UFW, но в облаках может быть ещё отдельный firewall. Не отключайте защиту целиком ради проверки.
  2. Дополнительная команда по теме
    Linux · Терминал (Bash)КомандаНужен sudo
    ufw может отсутствовать: тогда проверьте используемые nftables/iptables и правила провайдера.
    ip -br addr
    sudo ufw status verbose
  1. 6. Изменяйте только доказанную причину и перепроверьтеПосле исправления конфигурации приложения или прокси выполните его штатную проверку синтаксиса, затем согласованный перезапуск. Сверьте status, порт и ответ настоящего клиента. Если приложение отдаёт ответ 200 с ошибкой внутри JSON, проверяйте смысл ответа и журналы, а не только код HTTP.
  2. Команды проверки; не перезапускать производственный сервис без согласования
    Linux · Терминал (Bash)КомандаНужен sudo
    Команды проверки; не перезапускать производственный сервис без согласования.
    systemctl status ИМЯ.service --no-pager
    sudo ss -ltnp

#Как убедиться, что неисправность устранена

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

#Если результат не получен

Не повторяйте опасные действия наугад. Сохраните точную формулировку ошибки, вывод диагностики без секретов, версию Ubuntu и данные о затронутом компоненте. Верните лишь собственные изменения из резервной копии; если затронута загрузка, диски или рабочий сервер, воспользуйтесь консолью восстановления либо помощью администратора.

Так эту ошибку тоже называют

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.