Работа юнита в интервале времени — не завезли?

разве таймеры это не умеют? тоже интересна тема, подпишусь, sudo cast intelfx

Ну, я не нашёл, хотя ожидал. Может, плохо искал.

Включение и выключение по таймеру не предлагать — вдруг ребут и всё такое.

Почему не предлагать? С Persistent=yes не вижу проблемы:

# foo-start.timer
[Timer]
OnCalendar=08:00:00
Persistent=true
Unit=foo-start.service # Type=oneshot, `systemctl start ...`

# foo-stop.timer
[Timer]
OnCalendar=16:00:00
Persistent=true
Unit=foo-stop.service # Type=oneshot, `systemctl stop ...`

О, огонь.

см. edit

OnCalendar=, Persistent=

Type=oneshot, `systemctl start ...`

а это вообще кошерно так делать? дёргать systemctl из юнита?

¯\_(ツ)_/¯

Почему бы и нет?

В таймерах не требуется указывать юнит.

Жир, однако!

А, нет, вижу проблему.

Если машина будет выключена в промежуток с 8 по 16, а потом включится — выполнятся обе операции, причём не понятно, какая выполнится первой, а какая второй.

Нужно как минимум After= расставить (тогда юнит будет запущен и сразу же остановлен), или конфликты, а лучше дополнительные проверки, но это слишком костыльно уже выходит.

Ну вот да.

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

Я даже скорее не к вопросу синтаксиса, а к тому, что мне вся эта история довольно тривиальной кажется (независимо от systemd), но чего-то никакого адеквата я не вижу.

If a unit A that conflicts with a unit B is scheduled to be started at the same time as B, the transaction will either fail (in case both are required parts of the transaction) or be modified to be fixed (in case one or both jobs are not a required part of the transaction). In the latter case, the job that is not required will be removed, or in case both are not required, the unit that conflicts will be started and the unit that is conflicted is stopped.

Попробуй у foo-stop.service написать Conflicts=foo-start.service и в продакшен затестить.

Никогда не возникало такой задачи, не знаю, что предложить :)

Если сбрасывать противоположные таймеры: в старте - stop&start стоп-таймера, в стоп-сервисе - stop&start старт-таймера? Костылище, конечно.

Омг.

А чем это поможет? Только хуже будет. Машина спала с 4 утра до 20 вечера, старт-таймер взведён, стоп-таймер не взведён, просыпаемся — таймер срабатывает по Persistent, запускает foo-start.service, тот запускает foo.service и foo-stop.timer… и всё, foo-stop.timer сработает только на следующие сутки, foo.service работает, хотя не должен.

Чисто на таймерах полноценно с учётом ребутов похоже, что не решается.
У самого подобная задача, разруливаю конфликтами, но без учёта ребута.

Пока мысли такие, что первый старт должен выполнять предстартовый скрипт с проверкой времени, а далее таймеры.

Тогда тут только одно решение. Ставим 2 таймера на начало и конец запускающие один и тот же сервис. А сервис сам решает, что ему делать по времени, когда его дернули.

Я так, мимокрокодилом:
запилил в итоге скрипт с бесконечным циклом, который делает systemctl is active раз в минуту и всё сопутствующее. Грязновато, зато коротенько.