На своих серверах я привык все задачи писать в системный crontab, чтобы всё было в одном месте. Мне так удобнее управлять заданиями. Не надо проверять разные файлы. После планировщика Windows юниксовый cron очень понравился.
Сейчас на смену cron пришли systemd timers. Мне не особо нравится формат работы с ними, но приходится мириться и использовать, потому что всё больше софта по умолчанию свои задачи хранит там. Timers предлагают более широкий функционал по сравнению с cron и более гибкие настройки. Так что надо привыкать и пользоваться. Для этого решил сделать для себя шпаргалку и сразу поделиться с вами.
Сначала поясню, что умеют таймеры из того, что не умеет cron. Например, запустить какую-то задачу через заданное время после какого-то события. Для cron такое событие, насколько мне известно, может быть только — @reboot. Таймер же может запуститься, например, через некоторое время после завершения работы какого-то сервиса, возможно тоже вызванного по таймеру.
Таймер может проверять зависимости от других служб и не запускать задание, если какая-то служба недоступна. В случае cron подобную логику приходится реализовывать в самих скриптах. Например, проверять монтирование диска при бэкапе на удалённое хранилище.
Для каждого таймера systemd ведёт отдельный журнал, что удобно для отладки или анализа работы. Не надо грепать общий лог крона, или вообще системный лог, если по умолчанию cron не имеет отдельного журнала, как, например, в Debian. Я обычно это исправляю сразу же после установки системы.
В целом, удобство timers очевидно, хотя лично я ещё ни разу не сталкивался с ситуацией, где бы мне было проще и быстрее добавить таймер, а не воспользоваться cron. Для запуска скриптов крона вполне хватает. А с таймерами приходится взаимодействовать, когда настраиваешь какой-то софт. Например, certbot. Или смотришь системные залачи.
Посмотреть список всех таймеров:
# systemctl list-timers --allТолько активных:
# systemctl list-timersБолее подробная информация:
# systemctl status *timerПример создания таймера, который выполняет команду df -h. Сначала создаём конфигурацию сервиса в файле /etc/systemd/system/mydf.service:
[Unit]Description=Start df and log result in systemd journalWants=mydf.service[Service]Type=oneshotExecStart=/usr/bin/df -h[Install]WantedBy=multi-user.targetЗапустим и проверим результат. По умолчанию, вывод пишется в журнал systemd.
# systemctl start mydf.service# systemctl status mydf.serviceПосле нескольких запусков журнал можно посмотреть вот так:
# journalctl -u mydf.serviceДобавим задачу в планировщик, создав для неё минутный таймер в файле /etc/systemd/system/mydf.timer
[Unit]Description=Log df results every minuteRequires=mydf.service[Timer]Unit=mydf.serviceOnCalendar=*-*-* *:*:00[Install]WantedBy=timers.targetЗапускаем таймер:
# systemctl start mydf.timerЧерез несколько минут проверяем:
# journalctl -u mydf.serviceЕсли лог очень большой, его имеет смысл ограничить:
# journalctl -S "5min ago" -u mydf.serviceФормат systemd.time, в том числе и для таймеров, можно посмотреть в документации (сразу приведу шаблон DOW YYYY-MM-DD HH:MM:SS). Чаще всего при просмотре логов используется сокращение today или yesterday. То, что таймер пишет вывод в лог, удобно, но имейте ввиду, что за этим выводом стоит следить, если он большой.
Добавляем таймер в автозагрузку:
# systemctl enable mydf.timerУдаляем из автозагрузки и останавливаем:
# systemctl disable mydf.timer# systemctl stop mydf.timerПримеры служб и таймеров удобно посмотреть в уже готовых системных, в директории /lib/systemd/system. Показательны примеры для apt-daily и apt-daily-upgrade. Там и зависимости, и запуск одного после другого. Ну и про документацию не забываем.
#systemd #terminal #linux
