Подсистема инициализации и управления службами в Linux под названием Systemd плотно вошла в нашу повседневную рутину по управлению серверами. Есть в ней отдельный компонент Timers, который служит заменой классического планировщика мира Unix - cron.

Хочешь не хочешь, но с Timers работать придётся. В том же Debian 11 все повторяющиеся действия реализованы через timers и продублированы в старом cron. Список можно посмотреть вот так:
# systemctl list-timers
Увидите там logrotate.timer, man-db.timer, apt-daily.timer, apt-daily-upgrade.timer и т.д. Если установить php, certbot, то они также добавят свои таймеры наравне с записями в классический cron. Я так подозреваю, что в какой-то момент в обычном cron они исчезнут.

Можно по-разному относиться к нововведениям, но лично мне в таком виде они не нравятся. Это как в Windows функции размазались по Настройкам и Панели управления. В итоге приходится тратить больше времени на настройку и проверять всё в двух местах. Если уж переехали на таймеры, то в cron зачем дублировать? Там всё равно стоят проверки и если уже есть таймер для задачи, то cron ничего не делает. Но проверять приходится.

Когда я познакомился с Unix, его cron был одним из тех инструментов, который мне понравился больше всего. Простота и гибкость настройки подкупали. Все задания в одном файле. Просто скопировал и перенёс его на любой другой сервер, то есть очень простой бэкап всех заданий. Я даже на Windows устанавливал порт крона.

Смотрим на таймеры. Из удобств лично я увидел более гибкий планировщик, который может быть не только календарным, как в cron, но и событийным. Например, можно задать интервал на запуск через 10 минут после загрузки системы и потом повторять каждые 3 часа. Вроде удобно, но лично у меня никогда не было задачи, которой бы требовалось такое расписание. Ни разу не возникло ситуации, когда планировщик cron не справился бы. Максимум, иногда в скрипт добавишь sleep, но это редко бывает. Стараюсь так не делать, потому что костыль.

Вторым плюсом можно отметить логирование каждого отдельного таймера. Это удобно, но не сказать, что очень сильно надо. Grep общего лога cron с таким же успехом покажет все события отдельной задачи. В таймерах смотрим лог вот так:
# journalctl -u logrotate.timer

Ещё одним несомненным плюсом таймеров является возможность настройки зависимостей задач от других служб. Это реально удобно и в обычном cron никак не реализуется. Только если закладывать логику проверки в сам скрипт. Также таймеры могут быть присоединены к разным cgroups.

Я решил написать эту заметку, потому что на днях возникла простая задача. Надо было настроить периодический перезапуск службы 1С на Linux сервере. Прикинул, как это можно сделать через Timers. Получилась такая схема:
1. Создаём отдельную службу, которая перезапускает процесс srv1cv83.
2. Создаём таймер, который запускает эту службу.
Второй вариант, в описание самой службы srv1cv83 добавить параметр WatchdogSec, который будет автоматически перезапускать службу через заданный промежуток времени. Но так трудно попасть в конкретное время. Можно рано или поздно в середине рабочего дня перезапуститься.

Мне показалось, что проще просто добавить в crontab:
55 6 * * 7 root /usr/bin/systemctl restart srv1cv83
и перезапускать службу каждое воскресенье в 6:55. На этом решении в итоге и остановился.

А вы используете systemd timers? Какие задачи решаете? Может я туплю и не понимаю, как красиво и просто перезапускать в нужное время существующую работающую службу, управляемую systemd?

#linux #systemd #cron

На днях столкнулся в небольшой ошибкой в скриптах для бэкапа, когда настраивал их работу через cron. Я уже не раз упоминал, что в скриптах лучше всегда писать полные пути. Я это обычно соблюдаю, особенно для исполняемых файлов. А тут ошибся немного в другом.

Делал большой скрипт, где было много разных операций, в том числе одна из них была с rsync. Строка выглядела примерно так:

/usr/bin/rsync --progress -av --delete --delete-excluded --exclude-from=$EXCLUDE_LST -e "ssh -p 31008" user@1.2.3.4:/home/bitrix/ext_www/site01 /mnt/backups/site01/www --backup --backup-dir=/mnt/backups/site01/www_increment/`date +%Y-%m-%d`/`date +%H-%M-%S` 2>&1 >> /mnt/backups/site01/log.txt

Я тут раскрыл все переменные, чтобы было понятно, о чём идёт речь, кроме одной - $EXCLUDE_LST. Это файл со списком исключений. Задал его вот так:

EXCLUDE_LST=exclude-site01.lst

То есть просто указал на файл, который лежит тут же в директории. Когда отлаживаешь и запускаешь вручную - всё работает. А через cron - нет. А так как в скрипте было много различных действий, я сходу не смог понять, почему не работает конкретно эта синхронизация. Несколько раз глазами пробежал, не пойму, где ошибка и почему всё работает, а конкретно это не синхронизируется. Вывод rsync направлен в лог, обычно там его ошибки видно, но не в этот раз. Он просто не запускался.

Потом заглянул в системную почту, и там всё понятно:

rsync: [client] failed to open exclude file exclude-site01.lst: No such file or directory (2)
rsync error: error in file IO (code 11) at exclude.c(1481) [client=3.2.7]

Rsync просто даже не запускался из-за того, что не видел этот файл. В общем, очередное напоминание, что в скриптах лучше всегда всё писать с полными путями, чтобы потом не тратить время на отладку.

Кто-то может подсказать, как сделать так, чтобы в скрипте был относительный путь на файл, лежащий в этой же директории, и чтобы он корректно работал в cron. Я не могу сообразить, как это сделать. Всегда в списке переменных в самом начале пишу актуальные пути под конкретный сервер, чтобы потом с этим не разбираться.

#linux #cron