Comments 23
Возможные директивы слежения для systemd.path
К сожалению их мало, но базовые потребности для старта каких-либо юнитов они, в принципе, покрывают:
не совсем понял. У них семантика ИЛИ или все-таки И? Судя по комменту про пустую строку скорее И.
Семантика "ИЛИ", поэтому можно указывать несколько файлов/каталогов.
По поводу пустой строки — это такая фича, которая означает сброс ранее заданных параметров с данным именем. Часто ещё используется при переопределении поведения стандартных юнитов через systemctl edit <unit-name>. Пример из жизни — сокет-активация ssh-сервиса. По-умолчанию ssh.socket слушает порт 22, но если выполнить команду systemctl edit ssh.socket и в открывшимся редакторе прописать следующее:
[Socket]
ListenStream=
ListenStream=30013То systemd перестанет слушать порт 22, и будет слушать 30013. Без пустого параметра systemd будет слушать и новый порт (30013), и старый порт (22). Вот как-то так.
systemd.path увидел.
мониторить просто любые изменения и запускать недостаточно? Слишком часто?
Недостаточно, конечно. Синтетический пример — файл открыли, айподы кончились. Или файл открыли, пишем-пишем — место кончилось, а увидеть в системди это мы можем только, если файл закрылся.
Т.е. в системди это отловить можно, но уже после того, как проблема случилась.
Постоянно видел контроль за инодами.
Конечно, чертова автозамена ))))
Курс же по systemd, так давайте на полную)
/usr/lib/systemd/system, а потом удивляются, отчего их изменения превращаются в тыкву, после обновления пакета. Поэтому вот. Кстати не ты первый ;-).Ну как можно повлиять на то, над чем не имеешь контроля? Именно поэтому я и хочу переехать на rclone, но всё руки не дойдут.
Да. rclone через API яндекса работает, как я понял.
Systemd для продолжающих. Part 2 — Триггеры на различные события