Автор уверяет: systemd-таймеры лучше cron, и приводит «list-timers» как аргумент

Почему «вы недостаточно любите systemd-таймеры» вдруг набрало 376 очков

Пост «You don't love systemd timers enough» Тайлер Л. написал ещё в начале мая, но всплыл он только сейчас и собрал 376 очков и 238 комментариев. Тема старая и больная: cron работает на Unix десятилетиями, и предложение его заменить традиционно задевает нерв. Автор это понимает — в треде он назвал тему «третьим рельсом».

Что именно автор ставит в плюс таймерам перед cron

Аргумент поста — не «cron плохой», а «таймеры решают конкретные боли, которых у cron накопилось много». Конкретно автор перечисляет:

• Человекочитаемый календарь. Вместо загадочной строки вроде 01,31 04,05 1-15 1,6 * — OnCalendar=10:00, а проверить выражение можно командой systemd-analyze calendar.
• systemctl list-timers — единый обзор всех заданий в системе: когда запускались, когда сработают снова. У cron такой картины нет — нужно обойти crontab всех пользователей, /etc/cron.d/, /etc/cron.daily и так далее.
• Persistent= — пропущенный из-за выключенной машины запуск выполняется сразу после старта.
• RandomizedOffsetSec= / FixedRandomDelay= — разброс времени старта, чтобы сто машин не ударили по серверу одновременно.
• Логи в journald — stdout/stderr не исчезают в почте или «чёрной дыре», а ложатся в journalctl.
• ExecCondition=, OnFailure=, WakeSystem= — условный запуск, реакция на падение и пробуждение спящей системы под критичную задачу.

Ключевой тезис: таймеры умеют то, ради чего в мире cron приходится городить обвязку.

Тред: «PATH у cron тоже настраивается, а anacron уже есть»

Первым же ответом автору возразили по фактам. Утверждение, что у cron непредсказуемый $PATH, назвали натяжкой:

«Ты можешь задать PATH прямо в crontab. Чем это менее предсказуемо, чем когда он размазан по /etc/bashrc, ~/.bashrc, ~/.profile, ~/.bash_profile?» — инженер, оспоривший тезис про PATH

На аргумент про пропущенные запуски ответили, что у cron это давно решено:

«У cronie есть для этого механизм — anacron: он вызывается ежечасно и выполняет все задания cron.{daily,weekly,monthly}, даже если самое раннее возможное время было пропущено» — пользователь, указавший на anacron

А для перезагрузок напомнили про @reboot.

Где таймеры действительно выигрывают — голоса перешедших

Но немало участников треда подтвердили выгоду на своих задачах. Один описал ровно тот сценарий, под который сделан Persistent=:

«Перешёл с cronie на systemd-таймеры, потому что они устойчивы ко времени старта системы. У меня бэкап borg раз в день в фиксированное время — с cronie машина должна быть включена ровно в этот момент, а таймер просто запустит сервис, как только система станет доступна» — пользователь, переехавший ради бэкапов

Другой указал на гибкость, которой у cron нет вовсе:

«Таймеры умеют запускать произвольные юниты, не только одноимённый сервис. У меня таймер поднимает backup.target, который прогоняет цикл restic backup / prune / forget со случайным разбросом старта» — пользователь со связкой restic-таргетов

Отдельно хвалили интеграцию с journald — особенно на свежих системах вроде Debian 13, где syslog уже убрали.

«А теперь объясни это новичку»

Главная оговорка треда — не в мощности, а в пороге входа. Самый цитируемый скепсис:

«Я перевёл все свои cron-задания в systemd-таймеры и сервисы за год, но не могу избавиться от мысли, что это как-то… менее осязаемо, чем cron. Вот представь, что объясняешь таймеры, сервисы и unit-файлы новичку» — инженер, переехавший, но сомневающийся

Ему возразили, что баланс зависит от задачи:

«cron проще для простого (запусти это каждые 10 минут), но сложнее для сложного (запускай каждые 8 часов со случайным сдвигом, чтобы не все машины разом, и если машина была выключена — выполни немедленно)» — пользователь о границе применимости

Попутно всплыло, что спор местами ложный: в некоторых дистрибутивах есть systemd-cron — тонкая обёртка, где старый интерфейс crontab остаётся, а под капотом работает systemd.

Что в сухом остатке

Автор появился в треде лично и поблагодарил за фидбек, отметив: раз systemd теперь повсюду, освоить systemd-analyze и systemctl list-timers — практичный навык. Итог дискуссии трезвее заголовка поста: таймеры объективно мощнее для сложных сценариев — бэкапы с разбросом, пропущенные запуски, единый обзор, логи в journald. Но для «запусти раз в десять минут» одна строка cron по-прежнему быстрее и понятнее. Не «cron мёртв», а «выбирай по сложности задачи» — и теперь хотя бы знаешь, что у второго варианта есть list-timers.