Выражение event-a и event-b
истинно только после того, как были сгенерированы ОБА событие-a и событие-b, и если ваше задание выполняется, то ОБА события должны быть сгенерированы снова, чтобы быть правда.
Да, это возможно.
Простым способом было бы использование сценария оболочки, который многократно вызывал бы snapper
, по одному разу для каждой конфигурации. Кажется, для этого достаточно цикла for
.
Вы даже можете сделать это в файле модуля systemd:
ExecStart=/bin/sh -e -c '. /etc/conf.d/snapper; for conf in $$SNAPPER_CONFIGS; do /usr/bin/snapper --config "$$conf" --cleanup-algorithm number --description "boot"; done'
Обратите внимание, что вам нужно экранировать $
s, чтобы systemd не пытался интерпретировать их как системные переменные, а вместо этого позволял интерпретировать их оболочке. (На мой взгляд, использование сценария внешней оболочки, который вы вызываете в ExecStart=
, является более чистым подходом,тогда вам не нужно иметь дело с экранированием и не нужно втискивать все в одну строку.)
Другим вариантом может быть изменение самого snapper
, чтобы он мог обрабатывать это нативно. Скажем, заставьте его читать этот файл конфигурации и обрабатывать эти конфигурации всякий раз, когда он вызывается без каких-либо аргументов --config
. Это был бы еще более чистый подход.
Целесообразно это или нет... Наверное, это зависит от обстоятельств. Если вы получаете этот модуль snapper-boot.sevice
из пакета из вашего дистрибутива, у вас могут возникнуть проблемы всякий раз, когда обновление пакета затрагивает этот файл. Так что, в некотором смысле, это зависит от вашей конкретной ситуации.
Если этот юнит-файл действительно поставляется с пакетом из вашего дистрибутива Linux, вы можете открыть для них отчет об ошибке и попросить их избегать жесткого кодирования имен конфигураций в юнит-файле.
Если он не принадлежит вашему дистрибутиву, рассмотрите возможность сохранения его в /etc/systemd/system
, поскольку /usr/lib
обычно зарезервирован для файлов, поставляемых и управляемых дистрибутивом Linux.