Systemd timer

Прийшла пора розібратись із таймерами які нам надає Systemd на заміну старій добрій службі Cron.

Cron і досі надійно працює в системі але всі системні дії повязані із періодичним виконанням, принаймні в Debian вже переїхали на Systemd.timer значить і мені пора розібратись що воно таке і з чим його їдять.

Systemd – таймери мають деякі дуже цікаві можливості. Ці таймери, як і завдання cron, можуть, у заданий час, викликати виконання різних дій у системі. Наприклад – запуск скриптов командної оболонки або програм. Таймери можуть спрацьовувати, наприклад, раз у день, причому – тільки по понеділках. Ще один приклад – спрацьовування таймера кожні 15 хвилин у робочий час (з 8 ранку до 6 вечора). Але таймери systemd можуть дещо таке, що недоступно завданням cron. Наприклад, таймер може викликати скрипт або програму через заданий час після якоїсь події. Такою подією може бути завантаження системи або запуск systemd, завершення попереднього завдання або навіть завершення роботи сервісу, викликаного раніше по таймеру.

Спробуєм глянути на статус таймерів зареєстрованих для виконання в системі systemctl status –type=timer

● apt-daily-upgrade.timer - Daily apt upgrade and clean activities
     Loaded: loaded (/lib/systemd/system/apt-daily-upgrade.timer; enabled; preset: enabled)
     Active: active (waiting) since Tue 2024-07-23 20:43:41 EEST; 1 day 18h ago
    Trigger: Fri 2024-07-26 06:29:16 EEST; 15h left
   Triggers: ● apt-daily-upgrade.service

Jul 23 20:43:41 IoT systemd[1]: Started apt-daily-upgrade.timer - Daily apt upgrade and clean activities.

● apt-daily.timer - Daily apt download activities
     Loaded: loaded (/lib/systemd/system/apt-daily.timer; enabled; preset: enabled)
     Active: active (waiting) since Tue 2024-07-23 20:43:41 EEST; 1 day 18h ago
    Trigger: Fri 2024-07-26 01:41:05 EEST; 10h left
   Triggers: ● apt-daily.service

Jul 23 20:43:41 IoT systemd[1]: Started apt-daily.timer - Daily apt download activities.

● certbot.timer - Run certbot twice daily
     Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; preset: enabled)
     Active: active (waiting) since Tue 2024-07-23 20:43:41 EEST; 1 day 18h ago
    Trigger: Fri 2024-07-26 09:43:01 EEST; 18h left
   Triggers: ● certbot.service

Jul 23 20:43:41 IoT systemd[1]: Started certbot.timer - Run certbot twice daily.

● dpkg-db-backup.timer - Daily dpkg database backup timer
     Loaded: loaded (/lib/systemd/system/dpkg-db-backup.timer; enabled; preset: enabled)
     Active: active (waiting) since Tue 2024-07-23 20:43:41 EEST; 1 day 18h ago
    Trigger: Fri 2024-07-26 00:00:00 EEST; 9h left
   Triggers: ● dpkg-db-backup.service
       Docs: man:dpkg(1)

Jul 23 20:43:41 IoT systemd[1]: Started dpkg-db-backup.timer - Daily dpkg database backup timer.

● e2scrub_all.timer - Periodic ext4 Online Metadata Check for All Filesystems
     Loaded: loaded (/lib/systemd/system/e2scrub_all.timer; enabled; preset: enabled)
     Active: active (waiting) since Tue 2024-07-23 20:43:41 EEST; 1 day 18h ago
    Trigger: Sun 2024-07-28 03:10:35 EEST; 2 days left
   Triggers: ● e2scrub_all.service

Jul 23 20:43:41 IoT systemd[1]: Started e2scrub_all.timer - Periodic ext4 Online Metadata Check for All Filesystems.

● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; preset: enabled)
     Active: active (waiting) since Tue 2024-07-23 20:43:41 EEST; 1 day 18h ago
    Trigger: Mon 2024-07-29 00:41:08 EEST; 3 days left
   Triggers: ● fstrim.service
       Docs: man:fstrim

Jul 23 20:43:41 IoT systemd[1]: Started fstrim.timer - Discard unused blocks once a week.

● logrotate.timer - Daily rotation of log files
     Loaded: loaded (/lib/systemd/system/logrotate.timer; enabled; preset: enabled)
     Active: active (waiting) since Tue 2024-07-23 20:43:40 EEST; 1 day 18h ago
    Trigger: Fri 2024-07-26 00:00:00 EEST; 9h left
   Triggers: ● logrotate.service
       Docs: man:logrotate(8)
             man:logrotate.conf(5)

Jul 23 20:43:40 IoT systemd[1]: Started logrotate.timer - Daily rotation of log files.

З кожним таймером зв’язане, щонайменше , шість рядків, що містять відомості про нього:

• Перший рядок містить ім’я файлу таймера й короткий опис мети існування цього таймера.
• Другий рядок виводить відомості про стан таймера. А саме, повідомляє про те, чи завантажений він, дає повний шлях до файлу таймера, показує стан vendor preset (dіsabled або enabled).
• У третьому рядку показані відомості про активність таймера, куди входять дані про те, коли саме таймер був активований.
• У четвертому рядку втримуються дата й час наступного запуску таймера й зразковий час, що залишився до його запуску.
• П’ятий рядок повідомляє йм’я сервісу або події, викликуваного таймером.
• Деякі (але не все) файли юнитов таймерів systemd містять покажчики на документацію. Такі покажчики є, у моєму прикладі, в описах трьох таймерів.
• Останній рядок в описі таймера являє собою запис журналу, який пов’язана із самим свіжим екземпляром сервісу, викликаного таймером.

Створення таймера

Хоча ми могли б розібратися з особливостями роботи таймерів, проаналізувавши які-небудь існуючі таймери, я пропоную створити власний unіt- файл сервісу (файл конфігурації сервісу, servіce unіt) і файл таймера, за допомогою якого буде викликатися відповідний сервіс. Ми отут, щоб не ускладнювати оповідання, приведемо досить тривіальний приклад. Але після того як ми з ним розберемося, вам буде легше розібратися в роботі інших таймерів.

Для початку створимо простий файл конфігурації сервісу, який буде запускати щось простої, начебто команди free. Наприклад, це може знадобитися в тому випадку, якщо нам треба регулярно мониторить обсяг вільної пам’яті. Створимо unіt- файл із іменем monіtor.servіce у папці /etc/systemd/system. Він не обов’язково повинен мати атрибут на виконання.

# This service unit is for testing timer units
# By Dmytro Bernyk
# Licensed under GPL V2
#

[Unit]
Description=Logs system statistics to the systemd journal
Wants=monitor.timer

[Service]
Type=oneshot
ExecStart=/usr/bin/free

[Install]
WantedBy=multi-user.target

Цей файл, мабуть, можна назвати найпростішим файлом конфігурації сервісу. Тепер давайте перевіримо його стан і протестуємо його для того щоб переконатися в тому, що він працює так, як очікується.

Після зміни будь-яких юніт-файлів потрібно давати команду systemctl daemon-reload щоб systemd побачив внесені зміни.

root@IoT:/etc/systemd/system# systemctl status monitor.service
○ monitor.service - Logs system statistics to the systemd journal
     Loaded: loaded (/etc/systemd/system/monitor.service; disabled; preset: enabled)
     Active: inactive (dead)

А чому нічого не виводиться в консоль? Справа в тому, що за замовчуванням стандартний висновок (stdout) від програм, що запускаються systemd за допомогою unіt- файлов сервісів, перенаправляється в журнал systemd. Завдяки цьому, принаймні, доти, поки відповідні записи існують, ці записи можна проаналізувати. Заглянемо в журнал і пошукаємо запису, що ставляться до нашого сервісу й до дня, коли ми проводили випробування. Відповідна команда буде виглядати так: journalctl -S today -u monіtor.servіce. Ключ -S – це скорочений варіант –sіnce. Він дозволяє вказувати часовий період, за який утиліта journalctl шукає запису. Справа отут не в тому, що нас не цікавлять більш ранні результати. У нашому випадку таких результатів просто не буде. Цей ключ використано для того щоб скоротити час, який потрібно утиліті на пошук даних. Якщо комп’ютер працює вже давно, у журналі може нагромадитися дуже багато записів.

root@IoT:/etc/systemd/system# systemctl start monitor.service
root@IoT:/etc/systemd/system# journalctl -S today -u  monitor.service
Jul 25 15:11:34 IoT systemd[1]: Starting monitor.service - Logs system statistics to the systemd journal...
Jul 25 15:11:34 IoT free[188244]:                total        used        free      shared  buff/cache   available
Jul 25 15:11:34 IoT free[188244]: Mem:         3946592     2126132      157304      146944     2046400     1820460
Jul 25 15:11:34 IoT free[188244]: Swap:        1929212      190976     1738236
Jul 25 15:11:34 IoT systemd[1]: monitor.service: Deactivated successfully.
Jul 25 15:11:34 IoT systemd[1]: Finished monitor.service - Logs system statistics to the systemd journal.

Завдання, яке запускається за допомогою файлу конфігурації сервісу, може бути представлена окремою програмою, послідовністю програм, або скриптом, написаному на будь-якому скриптовом мові. Додамо в unіt- файл monіtor.servіce ще одне завдання, включивши в нього, наприкінці роздягнула [Servіce], що випливає:

ExecStart=/usr/bin/lsblk

Знову запустимо сервіс і перевіримо журнал. Там повинне бути щось, що нагадує те, що показане нижче. А саме, у журнал повинні потрапити дані, виведені обома командами:

root@IoT:/etc/systemd/system# systemctl start monitor.service
root@IoT:/etc/systemd/system# journalctl -S today -u  monitor.service
Jul 25 15:11:34 IoT systemd[1]: Starting monitor.service - Logs system statistics to the systemd journal...
Jul 25 15:11:34 IoT free[188244]:                total        used        free      shared  buff/cache   available
Jul 25 15:11:34 IoT free[188244]: Mem:         3946592     2126132      157304      146944     2046400     1820460
Jul 25 15:11:34 IoT free[188244]: Swap:        1929212      190976     1738236
Jul 25 15:11:34 IoT systemd[1]: monitor.service: Deactivated successfully.
Jul 25 15:11:34 IoT systemd[1]: Finished monitor.service - Logs system statistics to the systemd journal.
Jul 25 15:16:09 IoT systemd[1]: Starting monitor.service - Logs system statistics to the systemd journal...
Jul 25 15:16:09 IoT free[188653]:                total        used        free      shared  buff/cache   available
Jul 25 15:16:09 IoT free[188653]: Mem:         3946592     2099612      179716      146300     2049640     1846980
Jul 25 15:16:09 IoT free[188653]: Swap:        1929212      192512     1736700
Jul 25 15:16:09 IoT lsblk[188654]: NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
Jul 25 15:16:09 IoT lsblk[188654]: sda      8:0    0  14.9G  0 disk
Jul 25 15:16:09 IoT lsblk[188654]: ├─sda1   8:1    0   512M  0 part /boot/efi
Jul 25 15:16:09 IoT lsblk[188654]: ├─sda2   8:2    0  12.6G  0 part /
Jul 25 15:16:09 IoT lsblk[188654]: └─sda3   8:3    0   1.8G  0 part [SWAP]
Jul 25 15:16:09 IoT lsblk[188654]: sdb      8:16   0 465.8G  0 disk
Jul 25 15:16:09 IoT lsblk[188654]: └─sdb1   8:17   0 465.8G  0 part /var
Jul 25 15:16:09 IoT lsblk[188654]:                                  /home
Jul 25 15:16:09 IoT lsblk[188654]:                                  /mnt/sdb1
Jul 25 15:16:09 IoT systemd[1]: monitor.service: Deactivated successfully.
Jul 25 15:16:09 IoT systemd[1]: Finished monitor.service - Logs system statistics to the systemd journal.

Тепер, після того як ми впевнилися в тому, що все працює правильно, створимо, у папці /etc/systemd/system, unіt- файл таймера, давши йому ім’я monіtor.tіmer. У файл додамо наступне:

# This timer unit is for testing
# By Dmytro Bernyk
# Licensed under GPL V2
#

[Unit]
Description=Logs some system statistics to the systemd journal
Requires=monitor.service

[Timer]
Unit=monitor.service
OnCalendar=*-*-* *:*:00

[Install]
WantedBy=timers.target

Покажчик часу Oncalendar у цьому файлі, –* ::00, повинен приводити до того, що таймер виконує виклик юнита monіtor.servіce щохвилини . Докладніше про Oncalendar ми поговоримо нижче.

А поки ми можемо глянути на записі журналу, що мають відношення до запуску сервісу, викликуваного таймером. Ми, крім того, можемо включити режим спостереження за таймером. Однак спостереження за сервісом дозволить бачити результати практично в режимі реального часу. Для цього потрібно запустити journalctl із ключем -f (follow):

Тепер в іншій консолі запускаємо таймер, але не включаємо його в автозапуск при старті системи:

Понаблюдайте якийсь час за тим, що відбувається.

Один з результатів з’являється відразу ж. А наступні будуть виводитися з інтервалом приблизно в одну хвилину. Понаблюдайте за журналом кілька хвилин.

Jul 25 15:11:34 IoT systemd[1]: Starting monitor.service - Logs system statistics to the systemd journal...
Jul 25 15:11:34 IoT free[188244]:                total        used        free      shared  buff/cache   available
Jul 25 15:11:34 IoT free[188244]: Mem:         3946592     2126132      157304      146944     2046400     1820460
Jul 25 15:11:34 IoT free[188244]: Swap:        1929212      190976     1738236
Jul 25 15:11:34 IoT systemd[1]: monitor.service: Deactivated successfully.
Jul 25 15:11:34 IoT systemd[1]: Finished monitor.service - Logs system statistics to the systemd journal.
Jul 25 15:16:09 IoT systemd[1]: Starting monitor.service - Logs system statistics to the systemd journal...
Jul 25 15:16:09 IoT free[188653]:                total        used        free      shared  buff/cache   available
Jul 25 15:16:09 IoT free[188653]: Mem:         3946592     2099612      179716      146300     2049640     1846980
Jul 25 15:16:09 IoT free[188653]: Swap:        1929212      192512     1736700
Jul 25 15:16:09 IoT lsblk[188654]: NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
Jul 25 15:16:09 IoT lsblk[188654]: sda      8:0    0  14.9G  0 disk
Jul 25 15:16:09 IoT lsblk[188654]: ├─sda1   8:1    0   512M  0 part /boot/efi
Jul 25 15:16:09 IoT lsblk[188654]: ├─sda2   8:2    0  12.6G  0 part /
Jul 25 15:16:09 IoT lsblk[188654]: └─sda3   8:3    0   1.8G  0 part [SWAP]
Jul 25 15:16:09 IoT lsblk[188654]: sdb      8:16   0 465.8G  0 disk
Jul 25 15:16:09 IoT lsblk[188654]: └─sdb1   8:17   0 465.8G  0 part /var
Jul 25 15:16:09 IoT lsblk[188654]:                                  /home
Jul 25 15:16:09 IoT lsblk[188654]:                                  /mnt/sdb1
Jul 25 15:16:09 IoT systemd[1]: monitor.service: Deactivated successfully.
Jul 25 15:16:09 IoT systemd[1]: Finished monitor.service - Logs system statistics to the systemd journal.
Jul 25 15:22:05 IoT systemd[1]: Starting monitor.service - Logs system statistics to the systemd journal...
Jul 25 15:22:05 IoT free[189098]:                total        used        free      shared  buff/cache   available
Jul 25 15:22:05 IoT free[189098]: Mem:         3946592     2107184      170484      146336     2051272     1839408
Jul 25 15:22:05 IoT free[189098]: Swap:        1929212      192512     1736700
Jul 25 15:22:05 IoT lsblk[189099]: NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
Jul 25 15:22:05 IoT lsblk[189099]: sda      8:0    0  14.9G  0 disk
Jul 25 15:22:05 IoT lsblk[189099]: ├─sda1   8:1    0   512M  0 part /boot/efi
Jul 25 15:22:05 IoT lsblk[189099]: ├─sda2   8:2    0  12.6G  0 part /
Jul 25 15:22:05 IoT lsblk[189099]: └─sda3   8:3    0   1.8G  0 part [SWAP]
Jul 25 15:22:05 IoT lsblk[189099]: sdb      8:16   0 465.8G  0 disk
Jul 25 15:22:05 IoT lsblk[189099]: └─sdb1   8:17   0 465.8G  0 part /var
Jul 25 15:22:05 IoT lsblk[189099]:                                  /home
Jul 25 15:22:05 IoT lsblk[189099]:                                  /mnt/sdb1
Jul 25 15:22:05 IoT systemd[1]: monitor.service: Deactivated successfully.
Jul 25 15:22:05 IoT systemd[1]: Finished monitor.service - Logs system statistics to the systemd journal.
Jul 25 15:23:01 IoT systemd[1]: Starting monitor.service - Logs system statistics to the systemd journal...
Jul 25 15:23:01 IoT free[189154]:                total        used        free      shared  buff/cache   available
Jul 25 15:23:01 IoT free[189154]: Mem:         3946592     2072016      205428      146296     2051456     1874576
Jul 25 15:23:01 IoT free[189154]: Swap:        1929212      192512     1736700
Jul 25 15:23:01 IoT lsblk[189156]: NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
Jul 25 15:23:01 IoT lsblk[189156]: sda      8:0    0  14.9G  0 disk
Jul 25 15:23:01 IoT lsblk[189156]: ├─sda1   8:1    0   512M  0 part /boot/efi
Jul 25 15:23:01 IoT lsblk[189156]: ├─sda2   8:2    0  12.6G  0 part /
Jul 25 15:23:01 IoT lsblk[189156]: └─sda3   8:3    0   1.8G  0 part [SWAP]
Jul 25 15:23:01 IoT lsblk[189156]: sdb      8:16   0 465.8G  0 disk
Jul 25 15:23:01 IoT lsblk[189156]: └─sdb1   8:17   0 465.8G  0 part /var
Jul 25 15:23:01 IoT lsblk[189156]:                                  /home
Jul 25 15:23:01 IoT lsblk[189156]:                                  /mnt/sdb1
Jul 25 15:23:01 IoT systemd[1]: monitor.service: Deactivated successfully.
Jul 25 15:23:01 IoT systemd[1]: Finished monitor.service - Logs system statistics to the systemd journal.

Обов’язково перевірте й стан таймера, і стан сервісу.

Чи вдалося вам помітити отут те, що помітив я? Можливо, ви, читаючи журнал, зверніть увагу як мінімум на дві речі. По-перше – на те, що вам не потрібно робити щось особливе для логирования того, що Execstart з monіtor.servіce пише в stdout. Ця можливість входить у стандартні функції systemd по запускові сервісів. Але це означає, що вам, імовірно, буде потрібно проявляти обережність при запуску скриптов з файлів конфігурації сервісів, обертаючи увагу на те, який обсяг даних, який вони пишуть в stdout.

По-друге, ви могли звернути увагу на те, що таймер запускається не точно в :00 секунд кожної хвилини, і навіть не в точності через одну хвилину після попереднього запуску. Це – одна з особливостей подібних таймерів, якщо це потрібно (або якщо це зачіпає почуття системного адміністратора), така поведінка таймерів можна змінити, зробивши їх точніше.

Причина того, що таймер не запускається в :00 секунд кожної хвилини, полягає в тому, що система в такий спосіб прагне запобігти одночасному запуску декількох сервісів. Наприклад, при настроюванні покажчика часу Oncalendar можна користуватися такими значеннями, як Weekly, Daіly, та й іншими подібними. Ці скорочені способи іменування моментів часу настроєні так, щоб таймери, у яких вони використовуються, запускалися б в 00:00:00 відповідного дня. Коли так настроєна безліч таймерів, висока ймовірність того, що всі вони спрацюють одночасно.

Саме тому таймери systemd навмисно спроектовані так, щоб вони запускалися б не в точно зазначене час, а з деяким випадковим відхиленням від нього. Це відхилення не можна назвати зовсім випадковим. Таймери запускаються десь у тимчасовому вікні, яке починається із зазначеного моменту й закінчується моментом, що відстоять від вихідного на одну хвилину. Цей час, відповідно до документації до systemd.tіmer, підтримується в стабільному стані з обліком усіх інших оголошених у системі таймерів. У вищенаведеному фрагменті журналу можна бачити, що таймер спрацьовує відразу ж після його запуску, а потім – приблизно через 46 або 47 секунд після початку кожної наступної хвилини.

Найчастіше такий от імовірнісний підхід до визначення точного часу спрацьовування таймерів усіх улаштовує. При плануванні таких завдань, як, наприклад, виконання резервної копії чого-небудь, доти , поки подібні завдання виконуються в неробочий час, ніяких проблем це не викликає. Системний адміністратор, набудовуючи завдання cron, може вказати чітко певний час їх запуску, щось начебто 01:05:00, прагнучи до того, щоб ці завдання не конфліктували б з іншими. Існує великий набір способів вказівки часу, які подібне дозволяють. Випадкові зміни в часі запуску завдання, що не перевищують хвилину, звичайно особою ролі не відіграють.

Але для розв’язку деяких завдань точний час спрацьовування таймера надзвичайно важливо. У подібних випадках при настроюванні таймерів можна вказувати більш точний час їх спрацьовування (аж до точності, вимірюваної мікросекундами). Робиться це шляхом додавання у файл опису таймера, у розділ Tіmer, конструкції, що нагадує наступну:

AccuracySec=1us

Для вказівки бажаної точності таймера можна користуватися особливими ключовими словами. Ці ключові слова можна застосовувати й при настроюванні повторюваних і “одноразових” подій. Система розуміє наступні ключові слова:

Мікросекунда: usec, us, µs.
Миллисекунда: msec, ms.
Секунда: seconds, second, sec, s.
Хвилина: mіnutes, mіnute, mіn, m.
Година: hours, hour, hr, h.
День: days, day, d.
Тиждень: weeks, week, w.
Місяць: months, month, M (місяць визначений як 30,44 дня).
Рік: years, year, y (рік визначений як 365,25 дня).

Усі стандартні таймери, які є в /usr/lіb/systemd/system, настроєні з використанням набагато більш тривалих діапазонів, що задають точність їх запуску, тому що у випадку із цими таймерами спрацьовування їх у строго задане час не дуже важливо. Гляньте на специфікації деяких таймерів, створених системою:

root@IoT:/etc/systemd/system# grep Accur /usr/lib/systemd/system/*timer
/usr/lib/systemd/system/fstrim.timer:AccuracySec=1h
/usr/lib/systemd/system/logrotate.timer:AccuracySec=1h
/usr/lib/systemd/system/privoxy-cleanup.timer:AccuracySec=12h

Для того щоб краще познайомитися із внутрішнім обладнанням файлів таймерів з директорії /usr/lіb/systemd/system, ви можете переглянути їхній уміст.

Вам необов’язково набудовувати наш навчальний таймер так, щоб він активувався б при завантаженні системи. Правда, якщо прагнете – можете скористатися для цього такою командою: systemctl enable monitor.timer

root@IoT:/etc/systemd/system# systemctl enable monitor.timer
Created symlink /etc/systemd/system/timers.target.wants/monitor.timer → /etc/systemd/system/monitor.timer.

Файли таймерів, які ви будете створювати, не обов’язково повинні бути, що виконуються. Крім того, файли конфігурації сервісів не потрібно набудовувати так, щоб вони активувалися б при завантаженні, тому що їх викликають таймери. Якщо треба, сервіс можна викликати й вручну, з командного рядка. Спробуйте зробити це й загляньте в журнал systemd.

Для того щоб довідатися подробиці про точність таймерів, про способи вказівки часу виклику подій, про виклик подій, подивитеся документацію по systemd.tіmer і systemd.tіme.

Типи таймерів

Таймери systemd мають інші можливості, яких немає в завдань cron, “одноразових” або повторюваних, які викликаються тільки із прив’язкою до реального часу й до реальних дат. Таймери systemd можна настроїти так, щоб вони викликалися б на підставі зміни стану інших юнитов systemd. Наприклад, таймер можна настроїти так, щоб він спрацьовував би через заданий час після завантаження системи, після входу в неї користувача, або через заданий час після активації певного сервісу. Такі таймери називають монотонними (monotonіc). Ці таймери скидаються після кожного перезавантаження системи.

У наступній таблиці наведений список монотонних таймерів з короткою характеристикою кожного з них. Там же є й опис таймера Oncalendar, який монотонним не є й застосовується в тих випадках, коли потрібно організувати одноразовий або повторюваний запуск чого-небудь у майбутньому. Ця таблиця заснована на документації systemd.tіmer.

Таймер	Монотонний	Опис
OnActiveSec=	X	Час спрацьовування таймера задається щодо моменту активації таймера.
OnBootSec=	X	Час спрацьовування таймера задається щодо моменту завантаження системи.
OnStartupSec=	X	Час спрацьовування таймера визначається щодо першого запуску менеджера служб. У випадку із системними таймерами це дуже схоже на Onbootsec=, тому що системний менеджер служб звичайно запускається при завантаженні дуже рано. Подібні таймери, переважно, коштовні при використанні їх із прив’язкою до менеджерів служб, що ставляться до окремих користувачів, тому що такі менеджери служб звичайно запускаються тільки при першому вході користувача в систему, а не в процесі завантаження системи.
OnUnitActiveSec=	X	Час спрацьовування таймера задається щодо того часу, коли таймер, який повинен бути активований, був активований востаннє .
OnUnitInactiveSec=	X	Час спрацьовування таймера визначається щодо того часу, коли таймер, який повинен бути активований, був востаннє деактивирован.
OnCalendar=		Такий таймер прив’язаний до реального часу й орієнтується на події календаря. Подробиці про синтаксис описів подій календаря можна знайти в довідці по systemd.tіme(7). В іншому ж семантика описів таких таймерів схожа на таймери Onactіvesec=. Це – саме такі таймери systemd, які сильніше всього схожі на ті механізми, які застосовуються при настроюванні завдань cron.

При настроюванні монотонних таймерів можуть використовуватися ті ж ключові слова, що були описані вище при розмові про Accuracysec. Але треба відзначити, що systemd приводить відповідні тимчасові проміжки до секунд. Наприклад, вам потрібно задати таймер, який спрацьовує один раз, через п’ять днів після завантаження системи. Виглядати його опис може так: Onbootsec=5d. Якщо комп’ютер був завантажено 2020-06-15 в 09:45:27, то таймер спрацює 2020-06-20 в 09:45:27 (або в межах 1 хвилини після цього моменту часу).

Опис подій календаря

Застосування подій календаря – це ключова частина опису таймерів, викликуваних через певні проміжки часу. Розберемо деякі особливості таких подій, використовуваних при настроюванні покажчика часу Oncalendar.
В systemd і у відповідних таймерах використовується формат опису часу й дат, що відрізняється від того, який прийнятий в crontab. Цей формат є більш гнучким, чому той, що використовується в crontab. Він дозволяє вказувати дату й час у спрощеному виді, у стилі команди at. Тому, хто знаком з at, буде нескладно розібратися з настроюваннями таймерів systemd.
При використанні Oncalendar= для настроювання таймерів використовується наступний базовий формат для вказівки дати й часу:

DOW YYYY-MM-DD HH:MM:SS

DOW (Day Of Week, день тижня), це необов’язкова частина вищенаведеної конструкції. В інших полях можна використовувати символ зірочки (*), що символізує будь-яке значення, яке може перебувати в займаній їм позиції. Усі форми вказівки дати й часу приводяться до нормалізованої форми. Якщо час не зазначений, передбачається, що це – 00:00:00. Якщо дата не зазначена, а час зазначений, то таймер спрацює або в день його запуску (умовно говорячи, “сьогодні”), або наступного дня (“завтра”). Це залежить від поточного часу. Для вказівки місяців і днів тижні можуть використовуватися їхньої назви. Тут можна використовувати списки значень, поділювані комі. Діапазони значень можна розділяти трьома крапками (…), які ставлять між початковим і кінцевим значенням діапазону.

При вказівці дат у нашому розпорядженні є пари цікавих можливостей. Так, тильда (~) може використовуватися для вказівки останнього дня місяця, або для вказівки дати, на задану кількість днів попередньої останньому дню місяця. Коса риса (/) може застосовуватися, у вигляді модифікатора, для вказівки дня тижня.

У наступній таблиці показано кілька типових прикладів опису часу, використовуваних у вираженні Oncalendar.

Приклад представлення подій календаря  DOW YYYY-MM-DD HH:MM:SS	Опис
*-*-* 00:15:30	Щодня кожного місяця кожного року, через 15 хвилин 30 секунд після напівночі.
Weekly	Щопонеділка в 00:00:00.
Mon *-*-* 00:00:00	Те ж саме, що й Weekly.
Mon	Те ж саме, що й Weekly.
Wed 2020-*-*	Щосереди 2020 року в 00:00:00.
Mon..Fri 2021-*-*	Кожний будній день в 2021 році в 00:00:00.
2022-6,7,8-1,15 01:15:00	1 і 15 червня, липня й серпня 2022 року в 01:15:00 послу напівночі.
Mon *-05~03	Наступного разу , у будь-який рік, коли в травні понеділок буде днем, на 3 дня попереднім кінцю місяця.
Mon..Fri *-08~04	У будь-якому році, в 4 будній день, що передує кінцю серпня.
*-05~03/2	В 3 день, що передує кінцю травня, і потім – знову, через два дні. Повторюється щорічно. Зверніть увагу на те, що отут використаний знак ~.
*-05-03/2	У третій день травня, а потім – кожний другий день цього місяця. Повторюється щорічно. Зверніть увагу на те, що отут використане тире (-).

Тестування описів часу, використовуваних у подіях календаря

В systemd є відмінний інструмент для перевірки й дослідження специфікацій подій календаря. Мова йде про команду systemd-analyze calendar, яка розбирає описи подій календаря й представляє їх у нормалізованій формі. Ця команда дає й іншу цікаву інформацію, таку, як дата й час настання наступної такої події, і приблизний час, що залишився до досягнення цього моменту.

Для початку глянемо на специфікацію, яка містить тільки дату, не містить відомостей про час (зверніть увагу на те, що час у полях Next elapse і (іn UTC) різняться, ця відмінність залежить від місцевого годинного пояса):

[student@studentvm1 ~]$ systemd-analyze calendar 2030-06-17
  Original form: 2030-06-17                
Normalized form: 2030-06-17 00:00:00        
    Next elapse: Mon 2030-06-17 00:00:00 EDT
       (in UTC): Mon 2030-06-17 04:00:00 UTC
       From now: 10 years 0 months left    
[root@testvm1 system]#

Тепер додамо в опис відомості про час. У даному прикладі дата й час аналізуються роздільно, як сутності, не зв’язані один з одним:

[root@testvm1 system]# systemd-analyze calendar 2030-06-17 15:21:16
  Original form: 2030-06-17                
Normalized form: 2030-06-17 00:00:00        
    Next elapse: Mon 2030-06-17 00:00:00 EDT
       (in UTC): Mon 2030-06-17 04:00:00 UTC
       From now: 10 years 0 months left    

  Original form: 15:21:16                  
Normalized form: *-*-* 15:21:16            
    Next elapse: Mon 2020-06-15 15:21:16 EDT
       (in UTC): Mon 2020-06-15 19:21:16 UTC
       From now: 3h 55min left              
[root@testvm1 system]#

Тепер розглянемо приклад, у якому дата й час розглядаються спільно. Для цього їх потрібно взяти в лапки. Але якщо ви будете використовувати таку конструкцію в Oncalendar, не забудьте забрати лапки, інакше ви зіштовхнетеся з помилками:

[root@testvm1 system]# systemd-analyze calendar "2030-06-17 15:21:16"
Normalized form: 2030-06-17 15:21:16        
    Next elapse: Mon 2030-06-17 15:21:16 EDT
       (in UTC): Mon 2030-06-17 19:21:16 UTC
       From now: 10 years 0 months left    
[root@testvm1 system]#

Тепер давайте глянемо на опис Mon *-05~3, але цього разу запросимо в програми відомості про наступні 5 спрацьовування таймера, у якому використані такі настроювання:

[root@testvm1 ~]# systemd-analyze calendar --iterations=5 "Mon *-05~3"
  Original form: Mon *-05~3                
Normalized form: Mon *-05~03 00:00:00      
    Next elapse: Mon 2023-05-29 00:00:00 EDT
       (in UTC): Mon 2023-05-29 04:00:00 UTC
       From now: 2 years 11 months left    
       Iter. #2: Mon 2028-05-29 00:00:00 EDT
       (in UTC): Mon 2028-05-29 04:00:00 UTC
       From now: 7 years 11 months left    
       Iter. #3: Mon 2034-05-29 00:00:00 EDT
       (in UTC): Mon 2034-05-29 04:00:00 UTC
       From now: 13 years 11 months left    
       Iter. #4: Mon 2045-05-29 00:00:00 EDT
       (in UTC): Mon 2045-05-29 04:00:00 UTC
       From now: 24 years 11 months left    
       Iter. #5: Mon 2051-05-29 00:00:00 EDT
       (in UTC): Mon 2051-05-29 04:00:00 UTC
       From now: 30 years 11 months left    
[root@testvm1 ~]#

Уважаюся, ми розглянули досить прикладів використання systemd-analyze calendar, що дозволить вам приступитися до тестування власних описів подій календаря. Ураховуйте те, що засіб systemd-analyze має й інші цікаві можливості.

Додаткові матеріали

В Інтернеті є багато публікацій по systemd, але вони, в основному, занадто короткі, дуже спрощені, або навіть містять помилки. У цій статті наведені деякі гарні джерела інформації з systemd. Нижче даний список посилань ще на деякі якісні матеріали по цій темі.

Практичний посібник з systemd, підготовлене Fedora Project.
Шпаргалка від Fedora Project, у якій зіставлені команди старої системи Systemv і systemd.
Подробиці про systemd і про причини створення цієї системи.
Матеріал з відомостями й радами, присвячений systemd.
Матеріали Леннарта Поттеринга (Lennart Poetterіng), архітектора й основного розроблювача systemd. Ці матеріали призначені для системних адміністраторів, вони написано між квітнем 2010 року й вереснем 2011, але вони усе ще не втратили актуальності. Практично всі інші гідні публікації про systemd засновані на цих статтях.
Матеріал про керування датою й часом системи за допомогою systemd.
Стаття про керування запуском комп’ютера з використанням systemd.

Поцуплено з habr.com