Oxyd Jan 2 2021 at 20:08

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

10 min

35K

Configuring Linux*System administration**nix*

Tutorial

+68

Comments 23

0Karakurt0 Jan 2 2021 at 21:18

Хм. Такими темпами я свой vimonised на systemd перепишу)

Oxyd Jan 2 2021 at 21:25

Что там можно в systemd засунуть?

0Karakurt0 Jan 2 2021 at 21:31

Там сейчас костылём сделан таймер на отчистку «списка замороженных окон»; внутри демона. Вот его и можно, это будет намного точнее и аккуратнее отсчёта 300 циклов работы)
Можно даже будет попытаться снабдить каждое окно своим таймером, но это уже лишнее наверное.
Это кусок функционала undo у меня, если что.

Oxyd Jan 2 2021 at 21:45

Ну тогда отдельный *.target делай, что-б бардак не разводить и запускать/останавливать можно было скопом.

0Karakurt0 Jan 2 2021 at 22:05

Дай я логику сначала добью)
А тогда уже буду костыли убирать. Мне сейчас ещё надо с лексикой разобраться…
Большой плюс текущей версии в краткости, большинство самых частых команд укладываются в два нажатия. А в новой я вроде как реализовал чисто вимовское verb+noun+указатель, но теперь всё занимает три нажатия. И если в среднем норм, то, к примеру, в плеере это раздражает ( Do Player Next вместо Player Next).

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

gecube Jan 3 2021 at 11:59

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

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

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

Oxyd Jan 3 2021 at 12:24

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

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

gatoazul Jan 3 2021 at 14:51

уведомления на почту, если что-то пошло не так

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

kRosis Jan 3 2021 at 12:15

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

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

aryeh Jan 5 2021 at 12:18

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

Art_t_monenko Jan 5 2021 at 17:07

Спасибо за статью)

wakeup777 Jan 5 2021 at 17:08

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

Oxyd Jan 5 2021 at 17:15

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

gecube Jan 5 2021 at 17:22

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

Oxyd Jan 5 2021 at 18:30

Для пакетов, вендоры которых добавляют *.cron файлы, например. Кровавое легаси и это вот всё. Но от at я-б не отказался, например… но с systemd-шным синтаксисом задания времени, разумеется. И возможностью задания systemd-шных же параметров. Вообще странно, что в systemd не реализован cli интерфейс к таймерам. Какой-нить условный timerctl. А то systemctl list-timers Уж очень ограничен по функционалу. Кстати systemd-cron грамотно так реализован, всё по *.target-ам раскидано, например.

vodopad Jan 8 2021 at 23:46

После прочтения статьи так и не понял, что означает параметр OnActiveSec.

Oxyd Jan 9 2021 at 01:35

Ммм… Да, немного неудачно сформулировал. 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' 'Шарлотка сгорит!'

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

gecube Jan 9 2021 at 01:42

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

Oxyd Jan 9 2021 at 02:08

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