Подсистема инициализации и управления службами в 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

​​Одна из особенностей 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 journal
Wants=mydf.service

[Service]
Type=oneshot
ExecStart=/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 minute
Requires=mydf.service

[Timer]
Unit=mydf.service
OnCalendar=*-*-* *:*: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

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

Автозапуском сервиса управляет параметр Restart в разделе [Service]. Он может принимать следующие значения:
◽always — перезапускать всегда, когда сервис был остановлен корректно (exit code 0), с кодом ошибки или завис по таймауту
◽on-success — перезапускать, только если служба завершилась без ошибок (exit code 0)
◽on-failure — перезапускать, только если код завершения был не нулевым, был прибит одним из сигналов принудительного завершения работы (например SIGKILL), завис по таймауту
◽on-abnormal — перезапускать только если сервис был прибит одним из сигналов принудительного завершения работы или завис по таймауту
◽on-abort — перезапускать только если сервис был прибит одним из сигналов принудительного завершения работы
◽on-watchdog — перезапускать только если наступил настроенный для сервиса watchdog timeout
◽no — автоматического перезапуска нет

Надеюсь нигде не наврал. Перевёл кратенько отрывок документации, чтобы не притащить чьи-то ошибки. Так то в инете много статей по этой теме. По умолчанию, если явно не указан параметр, он принимает значение no.

Для того, чтобы настроить автоматический запуск сервиса, не надо редактировать его основной unit файл. Сделайте отдельный файл изменений override.conf и положите его в директорию сервиса со специальным именем. Для nginx оно будет такое: /etc/systemd/system/nginx.service.d/override.conf.

Добавьте туда:
[Service]
Restart=always
RestartSec=5s

После изменений надо перечитать настройки служб:
# systemctl daemon-reload

Теперь можно прибить Nginx и убедиться, что через 5 секунд он поднимется снова:
# systemctl status nginx ; смотрим pid корневого процесса (Main PID)
# kill -9 1910155
# systemctl status nginx

К автозапуску процессов надо подходить с умом. Не стоит для всех подряд его настраивать. Особенное внимание надо уделить службам СУБД. После аварийного завершения работы может запускаться очень ресурсоёмкая процедура восстановления данных, которая в нагруженном сервере может быть прибита oom killer и так по кругу. Это может привести к более серьезным последствиям или потере данных.

То же самое касается каких-то кластерных служб. Они могут падать и подниматься в цикле и приводить к рассинхронизации или каким-то ещё проблемам. Например, elasticsearch может подниматься очень долго на слабом железе. Иногда приходится стандартные таймауты systemd увеличивать, чтобы он удачно стартовал. Если настроить автозапуск, он может в цикле прибивать службу по таймауту.

А тот же самый Nginx, Postfix, Dovecot, Apache, Zabbix Agent можно спокойно ставить в автозапуск в случае падений. Проблем быть не должно.

У автозапуска есть более тонкие настройки и зависимости. Я описал только основной функционал, который нужен чаще всего. Более подробно всё описано в документации. Там настраиваются таймауты, различные статусы завершения работы, которые стоит считать успешными, количество попыток перезапуска, прежде чем они прекратятся и т.д. Можно слать оповещения на почту в случае падения и перезапуска службы. Это делается через параметр OnFailure.

Табличку себе сохраните на память для настройки. Без неё неочевидно, какой параметр лучше использовать. Например, Mariadb по умолчанию имеет настройку on-abort.

#systemd #linux

В современных дистрибутивах Linux почти везде вместо традиционных текстовых логов средствами syslog используются бинарные логи journald. Они также, как и текстовые логи, иногда разрастаются до больших размеров, так что необходимо заниматься чисткой. Вот об этом и будет заметка. На днях пришлось на одном сервере этим заняться, поэтому решил сразу оформить заметку. Написана она будет по мотивам Debian 11.

Смотрим, сколько логи занимают места:
# journalctl --disk-usage
Обычно они хранятся в директории /var/log/journal.

Настройки ротации логов могут быть заданы в файле /etc/systemd/journald.conf. Управляются они следующими параметрами:

[Journal]
SystemMaxUse=1024M
SystemMaxFileSize=50M

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

# systemctl restart systemd-journald.service

Так же вы можете обрезать логи в режиме реального времени. Примерно так:

# journalctl --vacuum-size=1024M
# journalctl --vacuum-time=7d

В первом случае обрезали старые логи, чтобы их осталось не больше 1024 мегабайт. Во втором обрезали все логи, старше 7-ми дней.

Кстати, если вы не хотите связываться с настройками journald, то можете команды выше просто в cron добавить на регулярное выполнение. Это тоже будет решение по ротации логов.

По умолчанию journald может занимать до 10% объёма раздела, на котором он находится. Но не более 4 Гб. На деле именно с ограничением в 4 Гб я чаще всего и сталкивался. Если у вас общий системный диск 40+ Гб, то как раз логи в 4 Гб у вас и будут.

Если у вас в логи спамит какая-то конкретная служба, то имеет смысл для неё отдельно настроить ограничение, выделив её логи в отдельный namespace. Для этого в unit службы в раздел [Service] добавьте отдельное пространство логов. Покажу на примере ssh. Запускаем редактирования юнита.
# systemctl edit ssh
Добавляем:
[Service]
LogNamespace=ssh

Создаём в директории /etc/systemd/ отдельный конфиг для этого namespace journald@ssh.conf со своими параметрами:

[Journal]
SystemMaxUse=20M

Перезапускаем службу:
# systemctl restart ssh

Смотрим его логи отдельно:
# journalctl --namespace ssh

Я, кстати, по старинке, всегда запускаю текстовые логи через syslog. Просто привык к ним. В итоге у меня и бинарные логи в journal, и текстовые в syslog. Примерно как с cron и timers. Через systemd больше функциональности и настройки гибче, но старые инструменты проще и быстрее в настройке.

#linux #logs #systemd #journal