enabled — значит ли сервис восстановится после reboot?

Проверяем сервис:

systemctl is-enabled nginx

Получаем:

enabled

На первый взгляд вывод очевиден:
после перезагрузки nginx автоматически запустится и снова будет работать.
Но enabled подтверждает значительно меньше.

Что на самом деле означает enabled

Для обычного systemd service unit состояние enabled означает, что сервис включён в механизм автоматического запуска — для него созданы необходимые связи с соответствующими target units.
Упрощённо:

nginx.service
      ↓
enabled
      ↓
должен быть включён в запуск
при достижении нужного target

Это подтверждение конфигурации автозапуска.
Но пока не подтверждение результата будущей загрузки.
Поэтому:

enabled
   ≠
успешно запустится после reboot

Почему сервис может быть enabled, но не запуститься

Причин достаточно много.
Например:

• ошибка в конфигурации приложения;
• недоступна зависимость;
• не смонтировалась файловая система;
• отсутствует нужный файл или secret;
• запят порт;
• неверные права доступа;
• сервис не дождался готовности сети;
• изменилась конфигурация после последнего успешного запуска;
• сработало условие systemd, запрещающее запуск;
• приложение запустилось и сразу завершилось с ошибкой.

При этом:

systemctl is-enabled service

по-прежнему может возвращать:

enabled

Потому что мы задаём systemd вопрос:
«Сервис настроен на автоматический запуск?»
а не:
«Сможет ли он успешно запуститься при следующей загрузке?»

Даже active + enabled недостаточно

Представим:

systemctl is-active nginx
→ active

и:

systemctl is-enabled nginx
→ enabled

Что мы доказали?

active
→ сервис запущен сейчас

enabled
→ автозапуск настроен

Но между этим и утверждением:
«После reboot сервис восстановится»
по-прежнему остаётся непроверенный участок.

работает сейчас
        +
автозапуск настроен
        ≠
успешное восстановление после reboot

Пример с зависимостью

Допустим, приложение использует отдельный filesystem:

/data

Сейчас он смонтирован, приложение работает:

application
    ↓
/data available
    ↓
active

После reboot диск по какой-то причине не смонтировался:

boot
   ↓
/data unavailable
   ↓
application start
   ↓
FAIL

Сам сервис всё это время остаётся:

enabled

Настройка автозапуска не изменилась.
Изменились условия, необходимые для успешного запуска.

Другой пример — сеть

Приложению при старте нужен удалённый сервис:

application
      ↓
remote database

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

enabled
      ↓
systemd попытался запустить сервис
      ↓
dependency недоступна
      ↓
service failed

То есть enabled может успешно привести к попытке запуска.
Но попытка запуска и успешное восстановление — разные вещи.

Как проверить сильнее

Сначала:

systemctl is-enabled nginx

отвечает на вопрос:
настроен ли автозапуск?
После реальной перезагрузки:

systemctl is-active nginx

проверяем:
запущен ли сервис сейчас?
Но для приложения этого тоже может быть недостаточно.
Например, для HTTP-сервиса дополнительно проверяем сам endpoint:

curl -f https://example.org/health

Тогда цепочка уже выглядит сильнее:

reboot
   ↓
service started
   ↓
application responds

А если reboot проводить нельзя?

На production-системе перезагрузка ради проверки может быть недопустима.
Тогда можно подтвердить отдельные части:

enabled
+
корректная конфигурация
+
успешный restart
+
доступность зависимостей

Это повышает уверенность.
Но важно правильно сформулировать результат:
предпосылки для автоматического восстановления подтверждены
а не:
восстановление после reboot проверено
Если само поведение после reboot не наблюдалось, мы его фактически не проверяли.

Главное

enabled
   ≠
успешный запуск
   ≠
работоспособное приложение
   ≠
восстановление после reboot

enabled — хороший факт.
Он подтверждает, что systemd настроен включать сервис в автоматический запуск.
Но эксплуатационная готовность требует более сильного доказательства:
система должна не только знать, что сервис нужно запустить, но и реально вернуть его в рабочее состояние после перезагрузки.

#Фактоскопия #Linux #systemd #ПоФактам