Real world применение таймер-юнитов

Что такое тайминг юниты? Коротко своими словами если можно.

Это такой недо-крон, встроенный в системд, только вместо одной строчки надо целый юнит-файл монстрячить.

Ну вот, допустим, есть возможность превратить systemd-run в своеобразный навороченный at(1). А сами таймер-юниты — да кому они интересны. Абстракция под капотом.

ну может вот есть расшареная sql база, с которой рабоают сервисы. И эти сервисы не используют delete на записи ибо это медленно, а помечают записи как исторические (update set deleted = true). Ну и заодним разработчику кода не нужно думать над сложными каскадами удаления.

И соответственно раз в N времени надо вызывать Garbage Collector, которые исторические записи или реально удалит через delete или забэкапит в отдельную таблицу, или разделенную на файлы таблицу - старые файлы отправит в бэкап.

и вот у каждого сервиса, общающегося с БД должен быть свой Garbage Collector, который должен работать только если работает исходный сервис. То же для дерева сервисов надо иметь дерево связанных коллекторов.

подойдет?

Я могу ошибаться, но в PostgreSQL такой подход к удалению записей используеися из коробки(autovacuum). То есть это опять же огород из костылей.

я могу ошибаться, но далеко не все могут себе позволить взять и сменить СУБД на PG только чтобы не пользоваться таймерами systemd.

тут ответ из двух частей,

1) update все равно быстрей delete
2) автовакуум это вообще хрен знает что такое, написанное на говноязыке (на си или си++) и поэтому неизменяемое для всех кроме авторов postgresql, повлиять на которое можно двумя с половиной параметрами. А свой собственный код ты можешь поменять как хочешь под конкретную задачу.
3) и уж тем более автовакуум не будет делать тебе кластерный бэкап =)
4) у тебя совершенно не обязательно там postgres, может быть древнючий mysql, в котором полный ад

5) но САМОЕ главное, ты не всегда технически можешь справиться со сложностью удаления записей в БД.

Например, у тебя софтина занимающаяся управлением корпорацией, и есть сущность (и соответственно таблица) «Организация». Сущность Организация связана с другими таблицами, они - с другими, полный граф может занимать сотни таблиц. Причем эти таблицы могут быть сделаны школьниками совершенно без знания о реляционных бд, без foreign keys, unique constraints, без возможности делать вменяемые джойны, каскады, и так далее.

Далее, ты хочешь удалить одну Организацию, и теперь вообще ХЗ как ее удалить, не поломав все-все содержимое БД, это ОЧЕНЬ сложно. Поэтому вместо физического удаления такая Организация обычно помечается как историческая, выставлением флага типа deleted (или скорее там ссылка на таблицу с описанием как именно она deleted, н-р «саму организацию удалить, а дочек оставить»)

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

То есть вполне вероятно, что «удалаляльщик записей» будет совершенно отдельной софтиной, написанной другими людьми в рамках другого проекта, и будет рабоать например как периодический Garbage Collector поверх основной софтины.

Можно предвосхитить события, и такую «архитектуру» планировать заранее, т.е. для каждого сервиса делать в сопровождение сервис timed GC.

И никакая автоматика встроенная в БД тут не поможет, если уж ты сам не знаешь что там и как происходит, как с этим разберется автоматика?

Как по мне, systemd timer юниты намного понятнее чем лапша из crontab.
Даже совсем непросвещённый человек сможет отредактировать юнит как ему угодно и ничего не сломается, в то время как при работе с cron ему придётся пердолить документацию

Здесь ты полностью прав, кейс совершенно валидный. Только вот такую логику можно реализовать с помощью крона, пинающего коллектор, у которого в Requisite= написаны нужные сервисы(коллектор не запустится, если указанные сервисы не запущены). Ну правда, это займёт сильно меньше телодвижений, а результат тот же.

Единственные ортогональные остальному feature set'у systemd директивы, которые я вижу в таймер-юнитах, - это OnBootSec=, OnUnitActiveSec= и OnUnitInactiveSec=, но и то логика последних двух зачастую реализуется в самом сервисе/приложении.

Чувак, вот это способен освоить любой пользователь(если он, конечно, не тупой осёл), у которого возникла необходимость запускать задачи по таймеру. Осваивается это меньше чем за минуту. Документация по таймер-юнитам(и вообще по всему машинариуму systemd) куда обширнее. Я очень сомневаюсь, что совсем непросвещённый человек без чтения мана поймёт разницу между OnActiveSec= и OnUnitActiveSec=. Выше по треду видно, что функциональность systemd и вовсе избыточна.

эти таймер юниты ущербны даже для обычного применения.

Они не умеют асинхронный старт задач, которые в одно время должны стартовать. Короче anacron/cronie никто не отменял.

Ман для systemd.timer занимает 89 строчек, структурирован он намного лучше и написан он более человечным языком.
Можно в одном терминале открыть ман, в другом открыть юнит и не менее эффективно справиться с задачей. Не надо даже гугла, не надо никаких картинок, никаких стрелочек и комментариев в конфиге — всё и без того понятно.
Если пользователь работал раньше с юнитами у него не возникнет никаких проблем.
И время там записывается не в таком упоротом формате как в crontab.

Я согласен, systemd далеко не идеален, но с ним зоопарк всевозможных утилит и конфигов, которые были ранее, превращаются в единую систему. И это замечательно

Надумано. В базах есть собственный механизм запуска джобов по расписанию.

Это не о том. Проблема зачастую в необходимости каскадного обновление зависимых таблиц и индексов. На пальцах: если ты решил снести ветку форума, то тебе ещё надо снести тысячи постов в это ветке - это лучше сделать в нонбизнес часы или самое тихое время, что не насиловать диски, а пока просто «скрыть» ветку.

А физически, разумеется никто не будет обнулять блоки - про них просто забывают.

Чувак, вот это способен освоить любой пользователь

Это ты, наверное, никогда по ошибке crontab -r вместо crontab -e не набирал.

этот код выполняется не на базе
то есть я конечно верю, что существуют олени, которые будут писать хранимки в базе и оборачивать в джобы, но их обычно увольняют раньше

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

С фига ли, дебилушка?

Собственно, у них немного разное назначение, и одно совсем не отменяется другое. systemd.timer нужны именно в привязке в systemd.service - позволяют взаимодействовать с юнитами. При этом, если у тебя нет юнита, а ты просто хочешь запускать скрипт или программу по таймеру, то cron никто [пока] не предлагает выкидывать.

systemd.timer не умеет много, что умеет cron. Например, у него нет доступа ко всем переменным окружения, он сам не может отсылать уведомления на почту.

Вот знаешь, никогда. Для тестирования cron-тасков я кладу их в /etc/cron.d/ и редактирую с помощью vim. Гораздо чаще я путаюсь в опциях scp, но я же не прошу Лёньчика заимплементить machinectl copyfile --port 8022 --recursive foo@bar:baz. В мире полно неочевидной ерунды, поэтому задача «бросить всё вотпрямщас и побежать перепиливать кронтабы в таймер-юниты из-за того, что я два раза в год путаю опции crontab» была бы в списке где-то после последнего пункта.