📁 systemd

Короткий ответ After/Before задают только порядок запуска относительно другого юнита, не создавая зависимости по факту успеха; Requires создаёт жёсткую зависимость — если требуемый юнит не запустился или упал, текущий юнит тоже останавливается; Wants создаёт мягкую зависимость — пытается запустить требуемый юнit, но продолжает работу, даже если тот не стартовал. Как это работает подробнее systemd строит граф зависимостей на основе всех этих директив и параллельно запускает независимые ветки юнитов, соблюдая порядок там, где он явно задан; важно помнить, что сама по себе директива Requires без After не гарантирует порядок запуска — она гарантирует только то, что оба юнита будут активны (или оба остановлены при сбое), а не последовательность их старта. Пример кода Что использовать на практике Практика. для сервиса, зависящего от базы данных на том же хосте, типично сочетание After=postgresql.service и Wants=postgresql.service (мягкая зависимость с порядком, не роняющая сервис, если БД временно недоступна при ст

Читать полностьюlinux

Короткий ответ Автоперезапуск настраивается директивами Restart= (например, on-failure или always) и RestartSec= в секции [Service]; защита от бесконечного цикла обеспечивается директивами StartLimitIntervalSec и StartLimitBurst, которые переводят юнит в состояние failed после превышения числа попыток за заданный интервал, вместо бесконечных рестартов. Как это работает подробнее systemd отслеживает код завершения и, если он подпадает под условие Restart= (on-failure реагирует на ненулевой код выхода или сигнал, always — на любое завершение), перезапускает сервис через RestartSec; при этом ведётся счётчик попыток запуска за скользящее окно StartLimitIntervalSec, и если число попыток превышает StartLimitBurst, systemd прекращает попытки и помечает юнит как failed, требуя ручного вмешательства. Пример кода Что использовать на практике Практика. без лимита на рестарты сервис, падающий из-за неисправимой проблемы (битая конфигурация, недоступная зависимость), будет бесконечно перезапускаться, создавая нагрузку на

Читать полностьюlinux

Короткий ответ Логи сервиса смотрят командой journalctl -u , для фильтрации по времени используют флаги --since и --until, а для просмотра в реальном времени — флаг -f (аналог tail -f). Как это работает подробнее journald централизованно собирает stdout/stderr процессов, запущенных через systemd, вместе со структурированными метаданными (unit, PID, время), и хранит их в бинарном индексированном формате, что позволяет быстро фильтровать без парсинга текстовых файлов. Пример кода Что использовать на практике Практика. при разборе инцидента полезно сузить вывод и по юниту, и по времени одновременно, а также использовать -p err для показа только сообщений уровня error и выше, чтобы не тонуть в общем потоке логов. Подводные камни Риск. Частая ошибка — искать логи сервиса в /var/log/syslog на системах, где используется journald без форвардинга в rsyslog, и не находить нужные записи просто потому что они лежат только в бинарном журнале systemd.

Читать полностьюjournalctl

Короткий ответ systemd timers интегрированы с journald (единые структурированные логи), поддерживают точный контроль пересечения запусков, автоматические повторные попытки, зависимость от других юнитов и системных событий (например, запуск после пробуждения из спячки), тогда как классический cron проще, но ограничен по этим возможностям и логирует через почту или отдельные файлы. Как это работает подробнее Таймер systemd — это отдельный .timer юнит, который по расписанию (OnCalendar) или по относительному времени (OnBootSec, OnUnitActiveSec) активирует связанный .service юнит; это позволяет переиспользовать весь функционал systemd для управляемого юнита — лимиты ресурсов, политику перезапуска при сбое, зависимости — чего нет у задачи cron, запускаемой напрямую демоном cron. Пример кода Что использовать на практике Практика. timers предпочтительны в современных дистрибутивах для задач, которым нужна гарантия выполнения (Persistent=true компенсирует пропущенные запуски при выключенном сервере), ограничение ресу

Читать полностьюcron