Комментарии 31
Возможные директивы слежения для 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, так давайте на полную)
/usr/lib/systemd/system, а потом удивляются, отчего их изменения превращаются в тыкву, после обновления пакета. Поэтому вот. Кстати не ты первый ;-).
Мне кажется, что для этого можно просто написать системди юнит с баш скриптом внутри, который будет реализовывать логику:
записываем текущий IP
спим 1 минуту
просыпаемся и получаем текущий IP
если текущий != старый do smth
PROFIT!
Вот даже на SO такое же рекомендуют - https://stackoverflow.com/a/37816847/698689
И еще одно готовое https://clinta.github.io/run-service-on-ip-change/
Реально - непаханое поле для велосипедостроения
Просто я рискнул предположить, что у systemd существует прямо такой ивент как смена адреса на интерфейсе. Вполне допускаю, что это у systemd-networkd запилено, но я им на домашнем сервере не пользуюсь (и не собираюсь). Если чего откопаю, напишу.
P.S.: это не от меня минус (у меня и полномочиев таких нет), я тоже удивлён, чего кому не понравилось.
Пожалуйста, мне вот тоже интересно, кто не согласен - пускай выйдет на свет божий и скажет, что не так. Но что-то мне подсказывает, что это просто некто ходит и мстит мне за мнение, альтернативное от его :-)
Просто я рискнул предположить, что у systemd существует прямо такой ивент как смена адреса на интерфейсе.
из того, что я вижу - очень сомнительно. Возможно у Пёттеринга есть планы запилить такой хук. Или возможно, что можно это отловить альтернативным способом - скажем, через d-bus, но настолько глубоко я не копал
- Нет
такой буквытакого ивента - Скриптом тоже можно, но разумнее напрячь dhclient
- Раз уж и так болтается в оперативной памяти Zabbix, почему бы ему не мониторить кроме того охренилиарда ещё один параметр.
В итоге я не стал ничего менять, ибо нефиг. Но вообще можно dhclient'ом дёргать чего-нибудь (и почему сразу в голову не пришло).
Вместо заббикса срочно рекомендую переходить на prometheus stack или https://www.netdata.cloud/
Netdata - TOP!
p.s. даже если не перейдете, то обогатите свой внутренний мир - альтернативы - это всегда хорошо!
В связи с тем, что incron выпилен из Debian 11, пришлось срочно переделывать логику на systemd.path.
Вопрос: в incron я мог в скрипт передать имя файла, когда мониторил каталог. Как это же реализовать в systemd логике? Где-то хранить старый список файлов и сравнивать?
Systemd для продолжающих. Part 2 — Триггеры на различные события