Post #1610

🧠 Хитрая DevOps-задача — неожиданное поведение systemd и зависимостей сервисов Задача: У вас есть два systemd-сервиса: backend.service и database.service. В юните backend.service вы прописали: [Unit] Requires=database.service After=database.service Но после перезагрузки системы backend.service запускается, хотя `database.service` не стартовал (из-за ошибки). Вопрос: Почему backend не дождался базы данных и не остановился вместе с ней, несмотря на Requires=database.service? Подсказка: это не баг systemd. Это особенность. Правильный ответ: Потому что Requires и After действуют только при запуске backend вручную или через systemctl, но не при автоматическом старте на boot, если backend стартует по WantedBy=multi-user.target. 🔍 Разбор - Requires=database.service говорит: если запускается backend, то systemd должен также запустить database. Но если database не стартует — backend всё равно может попытаться запуститься. - After=database.service определяет порядок запуска, но не делает зависимость "жёсткой". - При старте системы systemd может параллельно запускать сервисы, если backend привязан напрямую к multi-user.target и не указан как зависимость в database.service. ✅ Как правильно: Чтобы backend не запускался без базы: 1. Убедитесь, что database.service: - прописан как WantedBy=multi-user.target - и запускается первым 2. Убедитесь, что backend.service содержит: [Unit] Requires=database.service After=database.service StartLimitIntervalSec=0 3. И желательно добавить `PartOf=database.service`, если хотите, чтобы backend выключался вместе с базой. ⚠️ Вывод: - В systemd порядок и тип зависимостей — неочевидны. - Даже Requires не гарантирует, что другой сервис успешно работает — только то, что systemd *попробует* его запустить. - Хотите быть уверены — используйте Condition*, ExecStartPre с проверками или HealthCheck в Docker/K8s. 📌 systemd — мощный, но коварный. Не доверяй поверхностной логике — тестируй руками каждую зависимость.