Выбор между cron и таймерами и отладка пропущенных задач

cron vs. таймеры systemd: честный компромисс. Ни один инструмент не лучше универсально. Правильный выбор зависит от системы и от того, что нужно задаче.

cron:
  + Переносимый — работает на любой POSIX-системе: macOS, BSD, контейнеры без systemd
  + Одна строка конфигурации — никакого двухфайлового ритуала
  + Знаком — любой системный администратор знает синтаксис crontab
  - Нет логирования — вывод идёт на email или в /dev/null
  - Нет порядка зависимостей — нельзя сказать «запустить после network.target»
  - Нет наверстывания пропущенных запусков (без anacron)
  - Минимальное окружение — источник ошибок

Таймеры systemd:
  + Полное логирование journald — каждый запуск захвачен, с поиском, структурированно
  + Порядок зависимостей — After=, Wants=, BindsTo= работают в обычном режиме
  + Persistent=true для наверстывания после простоя
  + RandomizedDelaySec для распределения нагрузки
  + systemctl status и list-timers для видимости
  - Только systemd — бесполезен на Alpine, BSD, старых контейнерах
  - Двухфайловый шаблон для каждой задачи
  - После каждого изменения нужен daemon-reload

Правило большого пальца: используй cron для простых, переносимых, некритичных задач, где важна переносимость (виртуальный хостинг, контейнеры, скрипты, которые должны работать и на macOS). Используй таймеры systemd для всего на полноценном Linux-хосте с systemd, где важны логирование, наверстывание или зависимости — а это большинство продакшн-задач.

Причина 1 — неверный пользователь. Пользовательский crontab выполняется от имени этого пользователя. Корневой crontab — от имени root. Записи /etc/cron.d/ указывают пользователя явно. Несоответствие означает, что команда либо завершается с ошибкой (доступ запрещён), либо запускается в неожиданном контексте.

# Проверить, чей crontab содержит задачу:
crontab -l                    # твой собственный
sudo crontab -u alice -l      # crontab alice
sudo crontab -l               # crontab root

# В записях /etc/cron.d/ поле USER — шестой столбец:
grep backup /etc/cron.d/*
# /etc/cron.d/myapp:  0 2 * * * www-data /opt/app/backup.sh

# Проверить, была ли задача вообще вызвана (через спул почты или auth log):
sudo grep CRON /var/log/syslog | grep -i backup
# Jun 21 02:00:01 host CRON[3821]: (www-data) CMD (/opt/app/backup.sh)
# Эта строка означает, что cron ДЕЙСТВИТЕЛЬНО вызвал задачу — проблема в скрипте

Если строка CRON есть в syslog — задача была вызвана, сбой в скрипте. Если строки нет — cron никогда её не запускал.

Причина 2 — минимальный PATH; Причина 3 — неэкранированный % в cron. Два самых частых молчаливых сбоя.

# Ловушка PATH: скрипт использует бинарник не из /usr/bin:/bin
# Отладка: добавить явную строку PATH в crontab и логировать PATH при запуске
PATH=/usr/local/bin:/usr/bin:/bin
0 2 * * * env >> /tmp/cron-env.log && /opt/app/backup.sh >> /tmp/backup.log 2>&1
# Теперь /tmp/cron-env.log показывает точное окружение, используемое cron

# Ловушка с процентом: формат даты с % в команде crontab
# НЕВЕРНО — % становится переносом строки; команда усекается:
0 2 * * * /usr/bin/backup.sh > /tmp/backup-$(date +%Y%m%d).log

# ВЕРНО — экранировать каждый %:
0 2 * * * /usr/bin/backup.sh > /tmp/backup-$(date +\%Y\%m\%d).log

# Подтвердить, выполнив точно ту команду, которую запустил бы cron:
sudo -u www-data env -i HOME=/var/www SHELL=/bin/sh PATH=/usr/bin:/bin /bin/sh -c '/opt/app/backup.sh'

Трюк с env -i убирает твоё текущее окружение и запускает команду в голой оболочке — это максимально близко к воспроизведению окружения cron без ожидания самого cron.

Причина 4 — часовой пояс и DST; Причина 5 — отсутствие символа новой строки в конце crontab. Две менее очевидные ловушки.

# Часовой пояс: crond использует системный часовой пояс, если CRON_TZ не задан в crontab
# Проверить системный часовой пояс:
timedatectl status | grep "Time zone"
# Если система работает в UTC, а задача написана с расчётом на локальное время — она запустится в неверный час

# Исправление: задать CRON_TZ явно в crontab:
CRON_TZ=Europe/Moscow
0 2 * * * /usr/bin/backup.sh

# Ловушка DST: задача в 02:30 в ночь перевода часов назад запустится ДВАЖДЫ (02:30 будет дважды)
# Задача в 02:30 в ночь перевода часов вперёд будет ПРОПУЩЕНА (02:30 не существует)
# Не планируй критичные задачи в промежутке 01:00–03:00, если применяется DST

# Отсутствие переноса строки в конце: некоторые реализации cron молча игнорируют ПОСЛЕДНЮЮ СТРОКУ
# crontab, если она не заканчивается переносом строки. crontab -e добавляет его автоматически,
# но если скопировать в файл и установить через:
# crontab < /tmp/my-crontab
# ...последняя задача может никогда не запуститься. Всегда проверяй:
crontab -l | xxd | tail -3
# ...должно заканчиваться 0a (байт переноса строки)

Причина 6 — таймер не включён (systemd). Самый частый сбой таймера systemd — таймер существует, но не включён: он отображается в list-unit-files как disabled и никогда не срабатывает.

# Проверить статус таймера:
systemctl status db-backup.timer
# Loaded: loaded (/etc/systemd/system/db-backup.timer; disabled; ...)
#                                                        ^^^^^^^^
# 'disabled' означает, что он не переживёт перезагрузку и может не быть активным сейчас

# Разница:
# 'enabled' = установлен для запуска при загрузке (symlink в timers.target.wants/)
# 'active'  = работает/ожидает прямо сейчас
# Таймер может быть active (запущен вручную), но disabled (не перезапустится после перезагрузки)

systemctl is-enabled db-backup.timer    # enabled / disabled / static
systemctl is-active  db-backup.timer    # active / inactive / failed

# Исправление: включить И запустить одной командой:
systemctl enable --now db-backup.timer

# Также: daemon-reload обязателен после любого изменения файла юнита
systemctl daemon-reload
systemctl restart db-backup.timer

# Полная последовательность проверки после пропущенного таймера:
systemctl list-timers --all | grep db-backup
journalctl -u db-backup.service -b --since "yesterday"
journalctl -u db-backup.timer   -b --since "yesterday"