Сообщение failed у systemd описывает состояние службы, но не объясняет причину. Она могла не найти исполняемый файл, потерять доступ к каталогу, упереться в занятый порт или завершиться после ошибки конфигурации. Повторные restart без чтения первого сообщения иногда лишь стирают контекст и создают цикл сбоев.
Фото обложки: ENERGY.GOV; Cable racks at grid computing center, Fermilab with blue lights.jpg, Public domain. Уменьшение размеров и преобразование в WebP; кадрирование не выполнялось. Тематический снимок не изображает инфраструктуру упомянутых провайдеров.
Отделите unit, процесс и приложение
Unit содержит правила запуска, зависимости и параметры среды. Процесс может успешно стартовать, но приложение ещё не готово отвечать. Поэтому active не всегда равен успешной работе сайта, а inactive не обязательно ошибка для одноразовой задачи. Сначала определите тип службы и ожидаемую модель её жизни.
| Наблюдение | Что проверить |
|---|---|
| Unit not found | Имя, пакет, наличие unit и нужный system/user manager |
| Bad setting | Синтаксис и применимые директивы версии systemd |
| Permission denied | Пользователь, проход по каталогам, права и ограничения |
| Address in use | Какой процесс слушает выбранный адрес |
| Start limit hit | Первую причину повторных завершений, а не только счётчик |
| Active, но URL не работает | Готовность приложения, маршруты и зависимые сервисы |
Шаг 1. Уточните имя и область управления
Сервис может называться php8.2-fpm, php-fpm или иначе. Пользовательская служба управляется отдельно от системной. Не перебирайте массовые wildcard-команды остановки: сначала найдите точное имя. Для собственного приложения фиксируйте имя unit в документации развёртывания.
# example.service — условное имя, замените своим systemctl status example.service --no-pager --full systemctl show example.service -p LoadState -p ActiveState -p SubState -p Result systemctl cat example.service
Команды читают состояние. Вывод cat может содержать переменные и параметры с чувствительными данными; не публикуйте его целиком. Сохраните только нужный фрагмент после удаления секретов. Для user service используйте подходящий пользовательский контекст, а не переключайте всё на root ради удобства.
Шаг 2. Сопоставьте журнал с попыткой запуска
journalctl -u example.service --since '30 minutes ago' --no-pager journalctl -b -u example.service --no-pager
Окно времени ограничивает шум, а выбор текущей загрузки помогает отделить старый инцидент. Запишите часовой пояс и время попытки. Ищите первое содержательное сообщение до итогового failed: итог часто лишь сообщает, что команда завершилась ненулевым кодом.
Не считайте любой текст OOM доказательством нехватки памяти всей VM: приложение тоже может сообщать о собственном лимите. Для вывода нужен источник события, процесс и соседние записи. Если журнала нет, проверьте права чтения и выбранную область manager; не включайте публичную отладочную страницу.
Шаг 3. Разберите ExecStart и окружение
Проверьте существование файла, поддерживаемый способ запуска, рабочий каталог, пользователя и переменные. Команда, которая работает в интерактивном SSH, может зависеть от shell profile, текущего каталога и виртуального окружения. systemd не обязан воспроизводить интерактивную сессию.
Для Python путь к исполняемому файлу virtualenv задают осознанно; для PHP важна версия бинарного файла. Не переносите секретные переменные в аргументы команд, которые видны другим пользователям или попадут в журналы. Используйте предусмотренный проектом защищённый способ передачи окружения.
Шаг 4. Проверьте зависимости и порядок
Порядок After и требование зависимости решают разные задачи. Сам факт запуска службы после сети не доказывает доступность удалённой базы. Приложению может понадобиться собственная обработка повторного подключения и проверка готовности зависимого endpoint.
Если сервер не стартует из-за занятого порта, сначала определите владельца слушающего процесса. Не завершайте его вслепую: он может обслуживать рабочий сайт. Ошибка порта иногда связана с двумя экземплярами одной программы или оставшимся ручным запуском.
Шаг 5. Исправьте одну причину на стенде
Сохраните исходный unit и drop-in. Правки системного файла пакета могут затереться обновлением, поэтому используйте штатный механизм override, если он подходит задаче. Проверяйте настройки по документации установленной версии; директива из latest manual может отсутствовать на старой ОС.
После изменения описания manager должен перечитать конфигурацию штатным способом. Это не равнозначно перезапуску самого приложения. План применения включает оба действия в нужном порядке, проверку и возврат. На рабочем VPS согласуйте окно, если действие прерывает обработку запросов.
Практическая приёмка
- Unit загружен без ошибки синтаксиса.
- Процесс работает от ожидаемого пользователя и слушает нужный адрес.
- Контрольный URL возвращает ожидаемое содержимое.
- Приложение читает и сохраняет тестовые данные в разрешённой области.
- В журнале нет повторного цикла падений.
- После штатного перезапуска стенда служба ведёт себя по плану автозапуска.
reset-failed очищает отметку о сбое и связанные счётчики, но не лечит конфигурацию. Используйте его только после понимания причины. Автоматический restart полезен при предусмотренных временных сбоях, однако не должен скрывать постоянную ошибку или бесконтрольно создавать нагрузку.
FAQ
Почему active не означает рабочий сайт?
Проверяется состояние службы, а не каждая функция приложения. Нужна прикладная проверка маршрута и зависимостей.
Можно бесконечно повторять restart?
Сначала сохраните причину первой ошибки. Повторы могут создать цикл и ухудшить состояние общих ресурсов.
Нужно ли менять unit, если проблема в базе?
Исправление должно соответствовать причине. Неверный пароль или недоступный endpoint базы не исправляются случайным увеличением таймаута службы.
Вывод
Доказательная диагностика связывает состояние unit, конкретную попытку запуска, журнал и прикладной результат. Исправляйте установленную причину и сохраняйте проверяемый способ возврата.
Для смежных задач: 502 Bad Gateway на сайте: как найти неисправный слой, Логи WordPress и PHP: как собрать данные для исправления ошибки, Управляемый и неуправляемый VPS: как проверить регламент работ.
Источник технических параметров: официальная документация. Проверено 29.10.2026. Диагностический протокол — редакционная рекомендация; команды не выполнялись на сервере HOSTIO.
При выборе самостоятельного VPS учитывайте стоимость его обслуживания. Услуги Beget — подтверждённая партнёрская ссылка HOSTIO; характеристики нужного пакета проверяются отдельно.
