Systemd для продолжающих. Part 1 — Запуск юнитов по временным событиям

  • Tutorial

Всем привет! В последнее время я вплотную занимаюсь исследованием возможностей systemd и решил поделиться результатом исследований с сообществом, в виде небольшого (или большого, как пойдёт цикла статей. Итак первым (уже нет) номером нашей программы будет запуск юнитов по различным событиям происходящим во время работы ОС. В качестве исследовательской платформы будет выступать Manjaro Linux c systemd v247.2. И... да. Некоторые события, вынудили меня написать внеочередную статью, которая «взлетела на вершину хит-парада», а опрос показал, что тема актуальна и вызывает интерес, так что погнали!

Пролог

Systemd — система инициализации большинства современных систем на основе ядра Linux, обладает просто безграничными возможностями и не ограничивается обычным запуском демонов. Достаточно посмотреть на объёмы штатной документации, описывающей её возможности:

pacman -Ql $(pacman -Qsq systemd|xargs)|egrep '^systemd\s|^systemd-sysvcompat\s'|egrep "man/man[1|5|8]/[[:print:]]*\.gz"|wc -l
278

И это только маны описывающие конфиги, пользовательские и администраторские утилиты systemd. Если же не ограничивать поиск практической частью, то цифра будет ещё более «устрашающей»:

pacman -Ql $(pacman -Qsq systemd|xargs)|egrep '^systemd\s|^systemd-sysvcompat\s'|wc -l
1852

Большинство администраторов и разработчиков просто не представлют какие возможности таятся в недрах той системы, в окружении которых приходится работать их сервисам. Ну что-ж, пришлось время узнать, насколько глубока кроличья нора!

Disclamer: Хоть в официальной документации и манах почти не используется такое понятие как триггеры (хотя и используется «triggered by»), но все те штуки которые описаны в этой и следующей статье, по сути, именно ими и являются. Это сущности которые срабатывают по каким-либо событиям, поэтому не удивляйтесь, если я, авторским произволом, буду использовать этот термин.

Часть первая, очевидная. Таймеры.

Все мы знаем старый, добрый cron, во всех его проявлениях. Созданный ещё в 80-х, он, в том или ином виде, дожил до нашего времени облачных сервисов. Так же мы все знаем его ограничения. Например одной строчкой невозможно заставить крон запускать произвольный бинарник/скрипт раз в полтора часа, начиная с часа ночи, приходится описывать такое событие двумя строчками. Crontab файлы могут находиться в куче мест (/etc/crontab, /etc/cron.d/, /var/spool/cron). Cron не понимает нужно ли было стартовать сервис, если сервер был выключен и.т.д. Что бы обойти ограничения классического крона, в systemd были придуманы такие триггеры как таймеры (юниты с окончанием *.timer) умеющие запускать произвольные сервисы (*.service) или группы сервисов (*.target) периодически; по наступлении какого-либо времени; по выходу системы из спящего режима; по календарному событию (наподобие того как это делает другой ветеран Unix утилит, команда at), а так же по другим событиям, не связанными, напрямую, со временем. К заметному минусу, по сравнению с кроном, пожалуй можно указать то, что задание хранится в двух разных файлах (*.timer + *.service / *.target). С другой стороны это-же является и плюсом, ибо позволяет разделить логику запуска и логику времени срабатывания. Ну ладно, переходим к самому интересному.

Для начала… что запускаем. Возьмём, для примера, таймер man-db.timer из комплекта поставки одноимённого пакета:

$ cat /usr/lib/systemd/system/man-db.timer
[Unit]
Description=Daily man-db regeneration
Documentation=man:mandb(8)

[Timer]
OnCalendar=daily
AccuracySec=12h
Persistent=true

[Install]
WantedBy=timers.target

Простой, коротенький таймер. Но в чём-же дело, почему не указано что мы запускаем? Всё нормально! По умолчанию, если в секции [Timer] отсутствует параметр Unit=, с указанием запускаемого юнита, systemd будет искать одноимённый *.service юнит. Проверяем!

$ cat /usr/lib/systemd/system/man-db.service
[Unit]
Description=Daily man-db regeneration
Documentation=man:mandb(8)
ConditionACPower=true

[Service]
Type=oneshot
# Recover from deletion, per FHS.
ExecStart=+/usr/bin/install -d -o root -g root -m 0755 /var/cache/man
# Expunge old catman pages which have not been read in a week.
ExecStart=/usr/bin/find /var/cache/man -type f -name *.gz -atime +6 -delete
# Regenerate man database.
ExecStart=/usr/bin/mandb --quiet
User=root
Nice=19
IOSchedulingClass=idle
IOSchedulingPriority=7

Да, вот он сервис который ежедневно пересоздаёт базу данных страниц руководства. Сервис стартует начиная с 00:00 (OnCalendar=daily) , с точностью 12 часов (AccuracySec=12h), то-есть он может сработать в любой момент между полуночью и полднем, в зависимости от загрузки системы:

$ systemctl status man-db.timer 
● man-db.timer - Daily man-db regeneration
     Loaded: loaded (/usr/lib/systemd/system/man-db.timer; disabled; vendor preset: disabled)
     Active: active (waiting) since Thu 2020-12-31 23:18:59 MSK; 1 day 19h ago
    Trigger: Sun 2021-01-03 00:00:00 MSK; 5h 30min left
   Triggers: ● man-db.service
       Docs: man:mandb(8)

дек 31 23:18:59 dell-lnx systemd[1]: Started Daily man-db regeneration.

Минимальная точность у параметра AccuracySec= — 1us! Чем больше этот параметр, тем меньше нагрузка на систему. Если параметр отсутствует, то по умолчанию (указано в /etc/systemd/system.conf: DefaultTimerAccuracySec=) он равен одной минуте. Ладно, это всё лирика, давайте быстренько пробежимся по другим возможным параметрам секции [Timer], а на сладкое оставим параметры задания времени в OnCalendar= и других «временнЫх» параметрах.

Событийные таймеры

Таймеры привязанные к каким-либо событиям в системе.

  • OnBootSec= Таймер сработает через указанное время после старта системы.

  • OnStartupSec= Для системных таймеров действие аналогично предыдущему, для пользовательских таймеров, это время после первого логина пользователя в систему.

  • OnActiveSec= Через какое время, после активации таймера системным менеджером, запускать юнит (пример) .

«Монотонные» таймеры

Периодически запускаемые таймеры.

  • OnUnitActiveSec= Триггер будет ориентироваться на время последнего запуска целевого юнита.

  • OnUnitInactiveSec= Триггер будет ориентироваться на последнее время завершения работы целевого юнита. Хорошо для долгоиграющих сервисов. Бэкапы и вот это вот всё.

    Все вышеперечисленные таймеры можно комбинировать между собой и с таймером OnCalendar=.

Прочие параметры

  • RandomizedDelaySec= Этакий рандомный джиттер. Перед срабатыванием добавляется случайный таймаут от нуля, до заданного значения. По умолчанию -- отключено.

  • FixedRandomDelay= Связанный с предыдущим параметром булевый параметр. Если включено, то при первом срабатывании таймера, джиттер запомнится(и для этого таймера станет постоянным), но запомнится хитро. Сама генерация рандома будет основана на имени пользователя, имени таймера, а самое главное MachineID, о котором будет рассказано в одной из следующих статей и который гарантированно разный, на разных хостах. Для чего это нужно? Например имеем сеть с кучей хостов, которые, например в начале рабочего дня, запускают таймеры, юниты которых ломятся на сервер, устраивая шторм запросов. Что-бы таймеры гарантированно срабатывали в разное время и следует использовать этот параметр.

  • OnClockChange=, OnTimezoneChange= Булевые параметры, определяющие будет ли таймер реагировать на перевод системных часов или смену временной зоны. По умолчанию, оба параметра, false.

  • Persistent= Записывать-ли на диск состояние таймера сразу после запуска юнита. Актуально для параметра OnCalendar=. По умолчанию — false.

  • WakeSystem= Ещё один логический параметр. Действует на монотонные таймеры. По умолчанию отключён. Логика следующая. При отключённом параметре все монотонные таймеры запоминают своё состояние, перед уходом системы в спящий режим и встают на паузу. После выхода системы из спящего режима, отсчёт продолжается с того момента с которого система «ушла в спячку». Если-же параметр поставить в true, то таймеры продолжают работать и в спящем режиме (должно поддерживаться и железом) и по наступлении события выводят систему из спячки и запускают юнит.

  • RemainAfterElapse= Последняя крутилка, по умолчанию true Смысл этого параметра примерно следующий, После срабатывания таймера он остаётся загруженным, но если поставить false, то после срабатывания таймер выгружается и перестаёт отслеживать время. Хорошо для одноразовых юнитов (Transient Units) о которых мы поговорим в одной из следующих статей. Или для таймеров которые должны сработать один раз, как это делают задания старой, доброй at.

Таймстампы, диапазоны, тестирование, примеры

Ну и наконец зачем это всё. Чем хороши таймеры, так это тем, что всяческие сложные временные метки задаются гораздо проще чем в cron и задача запуска сервиса раз в полтора часа, начиная с часа ночи, выглядит куда приятнее. В самом простом случае она будет выглядеть так:

[Unit]
Description=Test timer

[Timer]
OnCalendar=01:00
OnUnitActiveSec=1.5h

Ну это слишком просто. Например мы хотим что-б наш юнит запускался каждую пятницу 13-е… OnCalendar=Fri *-*-13 12:00:00 Полный формат календарной формы выглядит так: Mon 2025-12-01 12:00:00.000000 Europe/Moscow Поэтому мы можем запускать таймер по времени другого часового пояса (по умолчанию текущий) Например хотим что-б таймер прислал нам уведомление, что Камчатка уже отпраздновала Новый год: OnCalendar=yearly Asia/Kamchatka Нормализованная форма будет выглядеть так(эти строчки указывают на одно и то-же время):
OnCalendar=*-01-01 00:00:00 Asia/Kamchatka Алиасы (и их эквиваленты в нормализованной форме) могут быть такими:

                       minutely → *-*-* *:*:00
                         hourly → *-*-* *:00:00
                          daily → *-*-* 00:00:00
                        monthly → *-*-01 00:00:00
                         weekly → Mon *-*-* 00:00:00
                         yearly → *-01-01 00:00:00
                      quarterly → *-01,04,07,10-01 00:00:00                                                      
                   semiannually → *-01,07-01 00:00:00

Примеры валидных таймстампов:

таймстамп с @ — epoch time
        Fri 2012-11-23 11:12:13 → Fri 2012-11-23 11:12:13
            2012-11-23 11:12:13 → Fri 2012-11-23 11:12:13
        2012-11-23 11:12:13 UTC → Fri 2012-11-23 19:12:13
                     2012-11-23 → Fri 2012-11-23 00:00:00
                       12-11-23 → Fri 2012-11-23 00:00:00
                       11:12:13 → Fri 2012-11-23 11:12:13
                          11:12 → Fri 2012-11-23 11:12:00
                            now → Fri 2012-11-23 18:15:22
                          today → Fri 2012-11-23 00:00:00
                      today UTC → Fri 2012-11-23 16:00:00
                      yesterday → Fri 2012-11-22 00:00:00
                       tomorrow → Fri 2012-11-24 00:00:00
      tomorrow Pacific/Auckland → Thu 2012-11-23 19:00:00
                       +3h30min → Fri 2012-11-23 21:45:22
                            -5s → Fri 2012-11-23 18:15:17
                      11min ago → Fri 2012-11-23 18:04:22
                    @1395716396 → Tue 2014-03-25 03:59:56

Здесь представлены таймстампы как для OnCalendar=, так и для монотонных таймеров.

Перечисления и диапазоны:

Боольшой список примеров
      Sat,Thu,Mon..Wed,Sat..Sun → Mon..Thu,Sat,Sun *-*-* 00:00:00
          Mon,Sun 12-*-* 2,1:23 → Mon,Sun 2012-*-* 01,02:23:00
                        Wed *-1 → Wed *-*-01 00:00:00
               Wed..Wed,Wed *-1 → Wed *-*-01 00:00:00
                     Wed, 17:48 → Wed *-*-* 17:48:00
    Wed..Sat,Tue 12-10-15 1:2:3 → Tue..Sat 2012-10-15 01:02:03
                    *-*-7 0:0:0 → *-*-07 00:00:00
                          10-15 → *-10-15 00:00:00
            monday *-12-* 17:00 → Mon *-12-* 17:00:00
      Mon,Fri *-*-3,1,2 *:30:45 → Mon,Fri *-*-01,02,03 *:30:45
           12,14,13,12:20,10,30 → *-*-* 12,13,14:10,20,30:00
                12..14:10,20,30 → *-*-* 12..14:10,20,30:00
      mon,fri *-1/2-1,3 *:30:45 → Mon,Fri *-01/2-01,03 *:30:45
                 03-05 08:05:40 → *-03-05 08:05:40
                       08:05:40 → *-*-* 08:05:40
                          05:40 → *-*-* 05:40:00
         Sat,Sun 12-05 08:05:40 → Sat,Sun *-12-05 08:05:40
               Sat,Sun 08:05:40 → Sat,Sun *-*-* 08:05:40
               2003-03-05 05:40 → 2003-03-05 05:40:00
     05:40:23.4200004/3.1700005 → *-*-* 05:40:23.420000/3.170001
                 2003-02..04-05 → 2003-02..04-05 00:00:00
           2003-03-05 05:40 UTC → 2003-03-05 05:40:00 UTC
                     2003-03-05 → 2003-03-05 00:00:00
                          03-05 → *-03-05 00:00:00
                         hourly → *-*-* *:00:00
                          daily → *-*-* 00:00:00
                      daily UTC → *-*-* 00:00:00 UTC
                        monthly → *-*-01 00:00:00
                         weekly → Mon *-*-* 00:00:00
        weekly Pacific/Auckland → Mon *-*-* 00:00:00 Pacific/Auckland
                         yearly → *-01-01 00:00:00
                       annually → *-01-01 00:00:00
                          *:2/3 → *-*-* *:02/3:00

Да. Микро и наносекунды тоже поддерживаются, а ещё очень удобная функция конца месяца и счётчик:

  • *-*~01 — Первый день с конца каждого месяца (он-же последний день месяца).

  • *-05~05 — 27-e мая каждого года (31-5).

  • Mon *-12~07/1 — Последний понедельник декабря.

  • Mon *-12-01/3 — Третий понедельник декабря.

Проверять таймстампы на валидность можно при помощи утилиты systemd-analyze:

$ systemd-analyze calendar 'Mon *-12-01/1'
  Original form: Mon *-12-01/1              
Normalized form: Mon *-12-01/1 00:00:00     
    Next elapse: Mon 2021-12-06 00:00:00 MSK
       (in UTC): Sun 2021-12-05 21:00:00 UTC
       From now: 11 months 2 days left

$ systemd-analyze timespan 1.5h
Original: 1.5h      
      μs: 5400000000
   Human: 1h 30min

$ systemd-analyze timestamp 01:00:30.9999
  Original form: 01:00:30.9999              
Normalized form: Sat 2021-01-02 01:00:30 MSK
       (in UTC): Fri 2021-01-01 22:00:30 UTC
   UNIX seconds: @1609538430.999900         
       From now: 18h ago 

Очень удобно реализован показ списка имеющихся в системе таймеров. Штатная утилита systemctl позволяет вывести список как активных, так и всех имеющихся в системе (ключик --all) таймеров.

$ systemctl list-timers
NEXT                        LEFT                   LAST                        PASSED     UNIT                         ACTIVATES                     
Sun 2021-01-03 14:01:00 MSK 7s left                Sun 2021-01-03 14:00:09 MSK 43s ago    cron-minutely.timer          cron-minutely.target          
Sun 2021-01-03 15:00:00 MSK 59min left             Sun 2021-01-03 14:00:09 MSK 43s ago    cron-hourly.timer            cron-hourly.target            
Sun 2021-01-03 23:35:59 MSK 9h left                Sat 2021-01-02 23:35:59 MSK 14h ago    systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Mon 2021-01-04 00:00:00 MSK 9h left                Sun 2021-01-03 00:00:09 MSK 14h ago    atop-rotate.timer            atop-rotate.service           
Mon 2021-01-04 00:00:00 MSK 9h left                Sun 2021-01-03 00:00:09 MSK 14h ago    cron-daily.timer             cron-daily.target             
Mon 2021-01-04 00:00:00 MSK 9h left                Mon 2020-12-28 00:00:35 MSK 6 days ago cron-weekly.timer            cron-weekly.target            
Mon 2021-01-04 00:00:00 MSK 9h left                Sun 2021-01-03 00:00:09 MSK 14h ago    logrotate.timer              logrotate.service             
Mon 2021-01-04 00:00:00 MSK 9h left                Sun 2021-01-03 00:00:09 MSK 14h ago    man-db.timer                 man-db.service                
Mon 2021-01-04 00:00:00 MSK 9h left                Sun 2021-01-03 00:00:09 MSK 14h ago    pkgfile-update.timer         pkgfile-update.service        
Mon 2021-01-04 00:00:00 MSK 9h left                Sun 2021-01-03 00:00:09 MSK 14h ago    shadow.timer                 shadow.service                
Mon 2021-01-04 00:00:00 MSK 9h left                Sun 2021-01-03 00:00:09 MSK 14h ago    updatedb.timer               updatedb.service              
Thu 2021-01-07 10:58:18 MSK 3 days left            Thu 2020-12-31 19:29:18 MSK 2 days ago pamac-mirrorlist.timer       pamac-mirrorlist.service      
Mon 2021-02-01 00:00:00 MSK 4 weeks 0 days left    Fri 2021-01-01 00:00:18 MSK 2 days ago cron-monthly.timer           cron-monthly.target           
Sat 2021-02-06 15:00:00 MSK 1 months 3 days left   Sat 2021-01-02 15:00:00 MSK 23h ago    pamac-cleancache.timer       pamac-cleancache.service      
Thu 2021-04-01 00:00:00 MSK 2 months 26 days left  Fri 2021-01-01 00:00:18 MSK 2 days ago cron-quarterly.timer         cron-quarterly.target         
Thu 2021-07-01 00:00:00 MSK 5 months 26 days left  Fri 2021-01-01 00:00:18 MSK 2 days ago cron-semi-annually.timer     cron-semi-annually.target     
Sat 2022-01-01 00:00:00 MSK 11 months 27 days left Fri 2021-01-01 00:00:18 MSK 2 days ago cron-yearly.timer            cron-yearly.target            
n/a                         n/a                    Thu 2020-12-31 23:19:21 MSK 2 days ago cron-boot.timer              cron-boot.target              

18 timers listed.
Pass --all to see loaded but inactive timers, too.

Вот так, в принципе, всё просто, логично и красиво. И разумеется напочитать:

man systemd.timer
man systemd.time
man systemd-system.conf
man systemd-analyze
man tzselect

Список статей серии

  1. Почему хабражители предпочитают велосипеды, вместо готовых решений? Или о systemd, part 0

  2. Systemd для продолжающих. Part 1 — Запуск юнитов по временным событиям

  3. Systemd для продолжающих. Part 2 — Триггеры на различные события

PS: Добавлена команда по выводу списка таймеров и плюсы-минусы таймеров, по сравнению с cron, в начале статьи. Спасибо @gecube!

PPS: Добавлены ссылки на ресурсы.

PPPS: Добавлено описание FixedRandomDelay= Довольно важный параметр о котором я успешно забыл.

Ресурсы

  • systemd.io — Статьи по внутренней кухне systemd. Частенько упоминается в манах.

  • systemd @ freedesktop.org — Основная страница с манами, документацией, видео, блогами и прочими ссылками на ресурсы.

  • @ru_systemd — Русскоязычный чат в Telegram. У нас тепло и лампово.

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 21

    +1
    Хм. Такими темпами я свой vimonised на systemd перепишу)
      0
      Что там можно в systemd засунуть?
        0
        Там сейчас костылём сделан таймер на отчистку «списка замороженных окон»; внутри демона. Вот его и можно, это будет намного точнее и аккуратнее отсчёта 300 циклов работы)
        Можно даже будет попытаться снабдить каждое окно своим таймером, но это уже лишнее наверное.
        Это кусок функционала undo у меня, если что.
          0
          Ну тогда отдельный *.target делай, что-б бардак не разводить и запускать/останавливать можно было скопом.
            0
            Дай я логику сначала добью)
            А тогда уже буду костыли убирать. Мне сейчас ещё надо с лексикой разобраться…
            Большой плюс текущей версии в краткости, большинство самых частых команд укладываются в два нажатия. А в новой я вроде как реализовал чисто вимовское verb+noun+указатель, но теперь всё занимает три нажатия. И если в среднем норм, то, к примеру, в плеере это раздражает ( Do Player Next вместо Player Next).

            Вот и думаю, как его сделать
      +1

      Очевидный плюс крона: "все расписания конкретного пользователя в одном месте", уведомления на почту, если что-то пошло не так
      Очевидный минус — в статье описано: куча мест, где может быть расписание (/etc/crontab, /etc/cron.d/, /var/spool/cron), cron не понимает нужно ли было стартовать сервис, если сервер был выключен, сложно строить гибкие расписания (приходится дублировать строчки).


      Очевидный плюс timers — они сильно более продвинутые, на них можно сделать все
      Минусы — иногда приходится писать x2 набор юнитов (*.timer, *.service), но это плата за гибкость


      В статье еще не хватает команд для "показать список всех таймеров" и "время их следующего срабатывания" (если что — это не analyze вроде) — в кроне такого нет )))

        0
        В статье еще не хватает команд для «показать список всех таймеров» и «время их следующего срабатывания» (если что — это не analyze вроде) — в кроне такого нет )))

        Спасибо, Что-то совсем из головы вылетело. Сейчас добавлю!
          0
          уведомления на почту, если что-то пошло не так


          Для систем без почтового сервера плюс так себе. Ошибки толком нигде не пишутся и их надо выуживать из системного лога.
          0

          По-моему, по сравнению с 0 частью статья потеряла лаконичность.


          Опишите, пожалуйста, в одной из будущих статей всё разнообразие триггеров. Коротко и без подробного вникание в каждый тип.

            +2
            где-ж эти статьи были в середине прошлого года?
            но я горд — почти всё сделал и как выясняется без костылей!
            спасибо, с огромным удовольствием прочитал и жду продолжения.
              +1
              Спасибо за статью)
                0

                Сдавал LPIC101-500(Jun level) летом, там был не плохой материал про это все, также был расстроен аналог at-> systemd-run
                https://learning.lpi.org/en/learning-materials/102-500/107/

                  0
                  Ну, на самом деле, аналог at можно сделать на основе проекта systemd-cron, возможно даже форкнув его и запросив PR в основной проект. Состояние юнитов в systemd-run не сохраняется между перезагрузками. Эта штука только для рантайма.
                    0

                    зачем это все, если есть systemd-timers?

                      0
                      Для пакетов, вендоры которых добавляют *.cron файлы, например. Кровавое легаси и это вот всё. Но от at я-б не отказался, например… но с systemd-шным синтаксисом задания времени, разумеется. И возможностью задания systemd-шных же параметров. Вообще странно, что в systemd не реализован cli интерфейс к таймерам. Какой-нить условный timerctl. А то systemctl list-timers Уж очень ограничен по функционалу. Кстати systemd-cron грамотно так реализован, всё по *.target-ам раскидано, например.
                  0
                  После прочтения статьи так и не понял, что означает параметр OnActiveSec.
                    +1
                    Ммм… Да, немного неудачно сформулировал. OnActiveSec= параметр задержки после активации таймера. То-есть, после того как таймер активирован системным менеджером, он сработает через OnActiveSec секунд. То-есть, допустим, у вас есть неактивный таймер, your.timer, с заданным параметром OnActiveSec=1.5h (разумется там могут быть и другие параметры срабатывания, тот-же OnCalendar=). Вы говорите sudo systemctl start your.timer и через полтора часа, после этого он сработает. Таким образом хорошо делать одноразовые пользовательские таймеры, запуская их через systemd-run например когда готовится какая-нибудь еда, а ты сидишь за компом. Например так (от пользователя):
                    systemd-run --user --timer-property=OnActiveSec=40m --unit=kitchen-timer.timer notify-send -u critical -a 'Kitchen Timer' 'Шарлотка сгорит!'

                    Выглядит это так (кликабельно):
                    Кликабельно!
                      0

                      Я бы все-таки подчеркнул разницу между OnActiveSec= и заданием времени запуска через ``OnCalendar= Просто не совсем понятно зачем откладывать запуск юнита черезOnActiveSec=```...

                        0
                        Ну вот, например, для одноразовых таймеров. Я немного переформатировал статью. Вынес логически близкие OnBoot / OnStartup / OnActiveSec в «событийные» таймеры, заодно поправил одну ошибку. У меня вместо OnUnitActiveSec= стояло просто OnActiveSec=
                    +1
                    Спасибо за статью

                    может быть `cat` заменить на
                    systemctl cat %unit%


                    Он сам покажет где файл лежит и все переопределения заодно
                    Unit-file может в разных местах лежать + раз уж мы про sysytemd говорим
                      0
                      Кстати да.

                    Only users with full accounts can post comments. Log in, please.