Как создавать таймеры systemd и управлять ими

Освоение единиц таймера Systemd: Полное руководство

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

Хотя cron десятилетиями был основным инструментом для планирования задач, таймеры systemd предлагают несколько преимуществ. Они могут быть напрямую связаны с единицами служб, что означает, что таймер может активировать службу только тогда, когда система готова, или служба может быть остановлена, если таймер истекает до завершения. Такая тесная интеграция упрощает управление сложными зависимостями. Кроме того, инфраструктура ведения журналов systemd (journald) предоставляет централизованный и доступный для поиска журнал всех действий таймеров, что значительно упрощает отладку по сравнению с просмотром разрозненных журналов cron.

Понимание структуры единицы таймера Systemd

Единица таймера systemd всегда сопряжена с соответствующей единицей службы (или другим типом единицы), которую она предназначена активировать. Сама единица таймера определяет, когда должна быть активирована связанная единица, в то время как единица службы определяет, какое действие выполнять. Обе единицы обычно располагаются в одном и том же каталоге, часто /etc/systemd/system/ для пользовательских единиц.

Типичный файл единицы таймера имеет расширение .timer, а его связанный файл единицы службы имеет расширение .service. Например, если вы хотите запланировать задачу, определенную в mytask.service, вы создадите файл mytask.timer.

Пример: Структура `mytask.timer`

[Unit]
Description=Run my custom task daily

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Давайте разберем ключевые секции:

Секция [Unit]:
- Description: Читаемое человеком описание таймера. Это полезно для идентификации в выводе статуса.
Секция [Timer]: Это ядро единицы таймера, определяющее расписание.
- OnCalendar=daily: Эта директива указывает, когда таймер должен активироваться. daily — это сокращение для *-*-* 00:00:00. Systemd поддерживает широкий спектр спецификаций календарных событий, аналогичных cron, но с большей гибкостью. Другие примеры включают:
  - hourly: Ежечасно.
  - weekly: Еженедельно (эквивалентно Mon *-*-* 00:00:00).
  - Sun *-*-* 10:00: Каждое воскресенье в 10 утра.
  - *-*-15 14:30: 15-го числа каждого месяца в 14:30.
  - Mon..Fri *-*-* 09:00: По будням в 9 утра.
- Persistent=true: Если установлено true, таймер активируется как можно скорее, если событие произошло, пока система была выключена. Для таймеров OnCalendar это означает, что если система была выключена в запланированное время, таймер сработает, как только система загрузится и таймер станет активным.
- OnBootSec=: Активирует таймер через указанное время после загрузки системы. Например, OnBootSec=15min сработает через 15 минут после загрузки.
- OnUnitActiveSec=: Активирует таймер через указанное время после того, как активируемая им единица (например, служба) последний раз стала активной. Например, OnUnitActiveSec=1h сработает через один час после того, как связанная служба последний раз завершила работу.
- OnUnitInactiveSec=: Активирует таймер через указанное время после того, как активируемая им единица последний раз стала неактивной.
- AccuracySec=: Указывает точность таймера. Systemd пытается вывести систему из спящего режима для таймеров только в том случае, если событие находится в пределах этого временного окна, что помогает экономить энергию. По умолчанию 1min.
- RandomizedDelaySec=: Добавляет случайную задержку к срабатыванию таймера до указанной длительности. Полезно для распределения нагрузки.
Секция [Install]: Эта секция определяет, как можно включить единицу таймера.
- WantedBy=timers.target: Эта директива гарантирует, что при включении таймера он станет частью timers.target, которая является стандартной целью, включающей все активные таймеры. Это означает, что таймер будет запускаться автоматически при загрузке после включения.

Пример: Структура `mytask.service`

[Unit]
Description=My custom task service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/my_custom_script.sh
User=myuser
Group=mygroup

[Install]
WantedBy=multi-user.target

Секция [Unit]:
- Description: Описание службы.
Секция [Service]: Это определяет саму службу.
- Type=oneshot: Подходит для задач, которые выполняются один раз, а затем завершаются. Существуют и другие типы для длительно работающих демонов.
- ExecStart: Команда для выполнения. Убедитесь, что скрипт имеет права на выполнение.
- User/Group: Указывает пользователя и группу, от имени которых должна выполняться команда. Хорошей практикой является не запускать задачи от имени root, если это не является абсолютно необходимым.
Секция [Install]: Эта секция обычно присутствует для служб, которые должны запускаться при загрузке, хотя для службы, запускаемой таймером, это может быть не строго необходимо, если она предназначена только для запуска таймером.

Создание и включение единиц таймера

Выполните следующие шаги для создания и управления единицами таймера systemd:

Создайте файл единицы службы: Определите свою задачу в файле .service. Поместите его в /etc/systemd/system/ (или ~/.config/systemd/user/ для таймеров, специфичных для пользователя).
bash sudo nano /etc/systemd/system/mytask.service
Вставьте пример содержимого службы выше и сохраните.
Создайте файл единицы таймера: Определите расписание в соответствующем файле .timer. Поместите его в тот же каталог, что и файл службы.
bash sudo nano /etc/systemd/system/mytask.timer
Вставьте пример содержимого таймера выше и сохраните.
Перезагрузите демон Systemd: После создания или изменения файлов единиц необходимо указать systemd перезагрузить его конфигурацию.
bash sudo systemctl daemon-reload
Включите таймер: Чтобы таймер запускался автоматически при загрузке, включите его.
bash sudo systemctl enable mytask.timer
Примечание: Вы НЕ включаете файл службы, если он предназначен исключительно для запуска таймером.
Запустите таймер: Запустите таймер немедленно. После этого он будет работать в соответствии со своим расписанием.
bash sudo systemctl start mytask.timer

Управление и мониторинг единиц таймера

Systemd предоставляет несколько команд systemctl для управления и мониторинга ваших таймеров:

Список всех таймеров: Просмотр всех активных и неактивных таймеров.
bash systemctl list-timers
Эта команда выдает вывод, подобный:
NEXT LEFT LAST PASSED UNIT ACTIVATES Tue 2023-10-27 08:00:00 UTC 10h left Wed 2023-10-26 08:00:00 UTC 14h ago mytask.timer mytask.service
Это показывает, когда таймер должен сработать в следующий раз, сколько времени осталось до его срабатывания, когда он сработал в последний раз и какую службу он активирует.
Список таймеров для конкретной единицы: Если вы хотите увидеть таймеры, связанные с конкретной службой.
bash systemctl list-timers --all | grep mytask.service
Проверить статус таймера: Получить подробную информацию о конкретном таймере.
bash systemctl status mytask.timer
Это покажет, активен ли таймер, когда он запланирован на следующий запуск, и последние записи журнала.
Просмотреть журналы службы: Чтобы увидеть вывод и статус задачи, выполненной таймером, проверьте журналы связанной службы.
bash journalctl -u mytask.service
Вы также можете следить за журналами в реальном времени:
bash journalctl -f -u mytask.service
Остановить таймер: Если вам нужно временно отключить таймер.
bash sudo systemctl stop mytask.timer
Отключить таймер: Чтобы предотвратить запуск таймера при загрузке и остановить его, если он работает.
bash sudo systemctl disable mytask.timer

Расширенные конфигурации таймера

Установка конкретных интервалов

Вместо daily или hourly вы можете определить более точные интервалы:

Каждые N минут: OnUnitActiveSec=15min (запускается через 15 минут после последнего завершения службы).
Конкретное время: OnCalendar=*-*-* 02:30:00 (запускается ежедневно в 2:30 утра).
Комбинирование условий: OnCalendar=Mon..Fri *-*-* 08:00:00 (запускается по будням в 8 утра).

Использование `AccuracySec` для экономии энергии

Если ваша задача не требует запуска в строго определенный момент, рассмотрите использование AccuracySec. Например, AccuracySec=5min сообщает systemd, что можно разбудить систему в течение 5 минут от запланированного времени. Это позволяет systemd группировать события таймера и потенциально дольше поддерживать систему в состоянии пониженного энергопотребления.

[Timer]
OnCalendar=hourly
AccuracySec=5min

`Persistent` против `WakeUpOn`

Persistent=true гарантирует, что если событие OnCalendar было пропущено из-за выключенной системы, оно будет выполнено один раз при следующей загрузке. Это критически важно для задач, которые нельзя пропускать.
WakeUpOn= (например, WakeUpOn=battery, WakeUpOn=ac) может использоваться для указания условий, при которых система должна просыпаться для таймеров. Это более продвинутая функция и часто используется в сочетании с systemd-suspend.service.

Таймеры против Cron

Функция	Таймеры Systemd	Cron
Интеграция	Глубокая интеграция со службами systemd, целями	Автономная утилита
Планирование	Гибкое (календарное, относительное, по загрузке)	В основном выражения, основанные на времени
Ведение журналов	Централизованное через `journalctl`	Разрозненное (`/var/log/syslog`, `/var/log/cron.log`)
Обработка ошибок	Может связывать действия с отказами службы	Базовые уведомления по почте
Зависимости	Может зависеть от активности других служб	Ограничено
Выполнение	Может запускаться от имени определенных пользователей, групп	Может запускаться от имени определенных пользователей через crontab
Управление питанием	Может быть оптимизировано для экономии энергии (`AccuracySec`)	Менее прямой контроль

Когда выбирать таймеры Systemd:

Когда вам нужна более тесная интеграция с другими службами systemd.
Когда централизованное ведение журналов и упрощенная отладка являются приоритетами.
Когда вам нужны более продвинутые параметры планирования (например, время с момента последнего запуска).
Для задач, связанных с состоянием системы или управлением питанием.

Когда Cron все еще может быть предпочтительным:

Для очень простых, автономных задач на системах, не полностью использующих systemd.
Для максимальной совместимости между различными дистрибутивами Linux и старыми системами.

Устранение распространенных проблем

Задача не выполняется:
- Проверьте статус таймера: systemctl status mytask.timer. Ищите сообщения Active: active и Triggered....
- Проверьте журналы службы: journalctl -u mytask.service. Убедитесь, что скрипт исполняем и не содержит ошибок.
- Проверьте синтаксис OnCalendar: Используйте systemd-analyze calendar 'your-calendar-string' для тестирования.
- Убедитесь, что таймер включен и запущен: systemctl list-timers --all.
Задача запускается слишком рано/поздно:
- Проверьте AccuracySec и RandomizedDelaySec.
- Убедитесь, что системные часы точны (timedatectl status).
Ошибки разрешений:
- Убедитесь, что User и Group, указанные в файле .service, имеют необходимые разрешения для скрипта и любых файлов, к которым он обращается.
- Если пользователь не указан, по умолчанию используется root. Будьте осторожны с привилегиями root.

Заключение

Единицы таймера Systemd предлагают надежный и современный подход к планированию задач в системах Linux. Понимая их структуру, создание и управление, вы сможете эффективно автоматизировать рутинные операции, повысить надежность системы и использовать всю мощь экосистемы systemd. Не забывайте всегда перезагружать демон после изменений, включать таймер для постоянства и использовать journalctl для эффективного мониторинга и устранения неполадок.