Unit service has failed: Main process exited, code=exited, status=1/FAILURE Linux / DevOps

status=1/FAILURE code=exited — Исправление ошибки запуска службы systemd

Обновлено: 18.08.2026 · Официальная база знаний

Архитектура ошибки и симптомы сбоя

Сообщение «Unit service has failed: Main process exited, code=exited, status=1/FAILURE» регистрируется диспетчером systemd. Ошибка означает, что основной исполняемый файл службы (ExecStart=) штатно завершил свою работу с базовым кодом ошибки 1 (General Error). Это универсальный код ошибки приложения, сигнализирующий о критической невозможности продолжить работу: занятый сетевой TCP/UDP порт, отсутствие прав на запись в директории /var/log/ или /var/run/, либо некорректные параметры в конфигурационном файле.

Диагностическая таблица параметров сбоя

Параметр	Значение	Инженерный смысл сбоя
code=exited	Clean Exit	Процесс не был убит сигналом или ядром, а сам принял решение о завершении.
status=1/FAILURE	Exit Status 1	Общий код ошибки приложения (Catchall for general errors).
Active State	failed (Result: exit-code)	Служба деактивирована и переведена в режим аварийной остановки.

Пошаговое дерево решений и сценарии траблшутинга

Сценарий 1: Проверка занятости сетевых портов (Address already in use)

Самая частая причина status=1/FAILURE — конфликт за сетевой порт (например, Nginx пытается занять порт 80, занятый Apache):

# Поиск процесса, занимающего требуемый порт (например, 80 или 443):
sudo ss -tulpn | grep -E ":(80|443|3306|5432)"

# Либо через lsof:
sudo lsof -i :80

Сценарий 2: Проверка прав доступа к рабочим каталогам и файлам PID/логов

Если служба работает под непривилегированным пользователем (директива User=app_user):

# Проверка владельца и прав на рабочие директории приложения:
ls -la /var/log/my_app/
ls -la /var/run/my_app/

# Восстановление прав на каталоги:
sudo chown -R app_user:app_group /var/log/my_app /var/lib/my_app /var/run/my_app
sudo chmod 755 /var/log/my_app

Сценарий 3: Проверка переменных окружения (EnvironmentFile)

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

# Просмотр подключенных EnvironmentFiles в unit-файле:
systemctl show service_name.service -p EnvironmentFiles

# Проверьте права и синтаксис файла (например, /etc/default/service_name):
cat /etc/default/service_name

Сценарий 4: Создание временных каталогов через RuntimeDirectory

Каталог /run очищается при перезагрузке. Используйте встроенный функционал systemd:

# В конфигурации сервиса (systemctl edit service_name):
[Service]
RuntimeDirectory=my_app
RuntimeDirectoryMode=0755
# systemd автоматически создаст /run/my_app с нужными правами перед запуском ExecStart!

Серверные службы падают с неинформативной ошибкой status=1/FAILURE?
ITSTM быстро локализует скрытые конфликты окружений, портов и прав доступа, восстановив работоспособность инфраструктуры.

Практический опыт инженера: Никогда не создавайте PID-файлы и сокеты в корне /var/run вручную скриптами. Всегда используйте стандартную директиву systemd RuntimeDirectory=appname — это исключает 90% ошибок прав доступа status=1 при ребутах.

Частые вопросы (FAQ)

Почему при ручном запуске от root служба работает, а через systemd падает с status=1?

При ручном запуске от root процесс имеет доступ ко всем файлам и полное окружение shell (PATH, HOME). systemd запускает службы в очищенном окружении с ограничениями прав (User=), песочницами (ProtectSystem=) и урезанным PATH.

Что означает статус status=13/PERMISSION?

Статус 13 (EACCES) явно указывает, что процесс попытался открыть файл или сокет, на который у пользователя службы нет прав на уровне файловой системы Linux.

Как сбросить состояние failed у юнита?

Выполните команду: sudo systemctl reset-failed service_name.service.

Как передать переменные окружения в сервис systemd?

Используйте директиву Environment="KEY=VALUE" или подключите внешний файл через EnvironmentFile=/etc/default/my_service в секции [Service].