Одна из особенностей Unix систем, которая меня сразу привлекла по сравнению с Windows, это наличие там CRON. По мне так это очень крутой, простой, удобный инструмент для управления периодическими задачами.
На своих серверах я привык все задачи писать в системный 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
>>Click here to continue<<
