Крон-планировщики (Cron Schedulers & Systemd Timers)

1. Обзор концепции и системная проблема

Веб-приложения и агентские системы не могут выполнять все операции внутри синхронного цикла обработки HTTP-запросов: длительные вычисления, индексация кодовых баз, формирование бухгалтерских отчетов, регулярные бэкапы баз данных и опрос внешних API приведут к таймаутам браузера и деградации интерфейса.

Классическое решение — вынесение фоновых операций на периодический запуск. Однако наивное использование расписания часто приводит к авариям в продакшене:

• Каскадное наложение задач (Job Pileup): когда база данных временно тормозит, новый экземпляр скрипта запускается до завершения старого, накапливая сотни зависших процессов, что полностью валит сервер.
• Тихий провал (Silent Failures): ошибки выполнения традиционного cron по умолчанию отправляются в локальную почту /var/mail/root, которую никто не читает, скрывая факт того, что бэкапы не создавались месяцами.

Cron Schedulers & Timers — это фундаментальная инфраструктурная подсистема, которая гарантирует детерминированный, надежный и контролируемый запуск фоновых процессов с централизованным логированием, ограничением ресурсов и взаимным блокированием.

2. Архитектурная таксономия и ментальная модель

Ландшафт планировщиков задач разделяется на три уровня изоляции и надежности:

┌─────────────────────────────────────────────────────────────┐
│                 SCHEDULER INFRASTRUCTURE MATRIX             │
├─────────────────────────────────────────────────────────────┤
│ 1. Operating System Native Tier                             │
│    • Linux Cron / Crontab (Проверка каждую минуту /etc/cron*)  │
│    • Systemd Timers (.timer + .service с cgroups и логами) │
├─────────────────────────────────────────────────────────────┤
│ 2. Application & Distributed Queue Tier                     │
│    • In-memory / Worker Queues (BullMQ, Redis, Celery)      │
│    • Durable Execution Engines (Temporal Workflows, Inngest)│
├─────────────────────────────────────────────────────────────┤
│ 3. Serverless & Cloud Trigger Tier                          │
│    • Cloudflare Cron Triggers / AWS EventBridge             │
│    • External Heartbeat Monitors (Healthchecks.io)          │
└─────────────────────────────────────────────────────────────┘

1. Системные таймеры Systemd (Современный стандарт Linux):
   • Состоят из двух юнитов: app-backup.service (команда выполнения и ограничение ресурсов) и app-backup.timer (расписание запуска). Обеспечивают перезапуск при сбоях и сохранение логов в journald.
2. Распределенные очереди (Distributed Job Queues):
   • Необходимы в многосерверных кластерах, где задачу должен выполнить ровно один воркер в системе (Leader Election через Redis или базу данных).
3. Механизм взаимного блокирования (Mutual Exclusion via Flock):
   • Системный вызов или утилита, создающая файловый дескриптор блокировки. Если предыдущий экземпляр еще жив, новый процесс немедленно завершается без нагрузки на систему.
4. Обратный мониторинг (Dead Man's Snitch / Heartbeat):
   • Принцип контроля, при котором скрипт в конце успешной работы отправляет HTTP-пинг на внешний мониторинг. Если сигнал не поступил в заданный промежуток времени, дежурный инженер получает алерты.

3. Технический пайплайн и внутренняя механика

Жизненный цикл периодической задачи с контролем надежности:

1. Оценка временного выражения (Cron Expression Matching): Планировщик каждую минуту парсит 5-позиционное выражение: $$\text{Минута (0-59)} \quad \text{Час (0-23)} \quad \text{День (1-31)} \quad \text{Месяц (1-12)} \quad \text{День недели (0-6)}$$
2. Попытка захвата блокировки (Flock Lock Acquisition): Скрипт вызывается через системную утилиту:

   flock -n /var/run/backup.lock /usr/local/bin/backup.sh
   

   Если файл заблокирован другим процессом — выход с кодом 0 без конфликта.
3. Инициализация полного окружения: Скрипт явно импортирует переменные окружения или запускается с полной декларацией путей:

   export PATH="/usr/local/bin:/usr/bin:/bin:$PATH"
   

4. Выполнение инженерной задачи: Процесс выполняет полезную работу, направляя вывод STDOUT и STDERR в журнал или файл ротации.
5. Отправка сигнала о успехе (Heartbeat Ping): В случае успешного завершения отправляется сигнал на мониторинг:

   curl -fsS -m 10 --retry 3 https://hc-ping.com/YOUR-UUID
   

6. Освобождение блокировки: Файловый дескриптор закрывается, ресурсы освобождаются.

4. Практические инженерные сценарии в продакшене

01. Резервное копирование базы PostgreSQL в S3 через Systemd Timer

Настройка надежного ежедневного бэкапа без сторонних PaaS:

• Создается юнит /etc/systemd/system/pg-backup.service:

  [Unit]
  Description=PostgreSQL Nightly S3 Backup
  After=network-online.target
  
  [Service]
  Type=oneshot
  User=postgres
  ExecStart=/usr/local/bin/pg-backup-to-s3.sh
  MemoryMax=2G
  

• Создается таймер /etc/systemd/system/pg-backup.timer:

  [Timer]
  OnCalendar=*-*-* 03:00:00
  Persistent=true
  
  [Install]
  WantedBy=timers.target
  

• Флаг Persistent=true гарантирует, что если сервер был выключен в 3:00 ночи, бэкап выполнится сразу после его включения.

02. Ежечасное переиндексирование кодовой базы для AI-ассистентов

Поддержка свежего векторного индекса репозитория:

• Скрипт ежечасно проверяет команду git fetch. Если появились новые коммиты, запускается легковесный воркер, который генерирует новые эмбеддинги только для измененных файлов и обновляет таблицы SQLite-vec.

03. Безопасное очищение сессий и старых логов (Log Rotation)

Предотвращение переполнения системного накопителя:

• Cron каждую ночь запускает утилиту удаления временных загрузок старше 48 часов:

  find /var/www/uploads/tmp -type f -mtime +2 -delete
  

5. Подводные камни, типовые ошибки и безопасность

• Отсутствие абсолютных путей в командах: Запись node server.js в crontab упадет с ошибкой command not found. Всегда указывайте точный путь: /home/deploy/.nvm/versions/node/v22.0.0/bin/node /var/www/app/server.js.
• Путаница с часовыми поясами (UTC vs. Local Time): Серверы по умолчанию настроены на UTC. Если вы укажете запуск в 04:00 по киевскому времени без учета смещения, задача выполнится в 06:00 или 07:00, когда нагрузка на систему уже достигнет пика.
• Отсутствие таймаутов на сетевые вызовы: Если скрипт внутри cron делает curl к внешнему серверу без флага --max-time 30, зависший сокет может заблокировать процесс на недели.
• Слепое ожидание от crontab без проверки логов: Периодически проверяйте работоспособность фоновых задач через grep CRON /var/log/syslog или настраивайте автоматические уведомления в случае сбоев.