Крон-планувальники (Cron Schedulers & Systemd Timers)(Планувальники фонових задач, Cron та системні таймери)

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 або налаштовуйте автоматичні сповіщення у разі збоїв.