LINUX.ORG.RU

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

 ,


1

3

Всё просто. Есть юнит, который должен быть active с 8 утра до 16 вечера.

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

Правда ничего не завезли для этого, или плохо смотрю? В принципе, не обязательно systemd.

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

Почему не предлагать? С 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 ...`
intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1 )
Ответ на: комментарий от intelfx

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

anonymous ()
Ответ на: комментарий от Dispetcher14

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

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

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

intelfx ★★★★★ ()
Ответ на: комментарий от Dispetcher14

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

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

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

Dispetcher14 ★★★★★ ()
Последнее исправление: Dispetcher14 (всего исправлений: 1 )
Ответ на: комментарий от intelfx

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 и в продакшен затестить.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 2 )
Ответ на: комментарий от Dispetcher14

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

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

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

anonymous ()
Ответ на: комментарий от anonymous

Омг.

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1 )

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

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

surefire ★★★ ()
Ответ на: комментарий от intelfx

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

anonymous ()
Ответ на: комментарий от intelfx

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

Dispetcher14 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.