Для того чтобы демон ИБП мог потушить весь сервер ему нужны соответствующие права, а он может быть запущен с понижением привилегий. И послать сигнал SIGPWR иниту он может, а вот уже запустить /sbin/shutdown — рожей не вышел.
В воскресенье 24 сентябрь 2023 10:58:55 (+03:00), Max Nikulin пишет: > On 24/09/2023 01:52, Andrey Jr. Melnikov wrote: > > Вот и смотри - есть демон, который мониторит сосотяние UPS'a - пропало > > питание - посылает сигнал, появилось - посылает сигнал (ну тут всё > > стандартно, так уже лет 40 делают). Просто удобнее, когда у тебя есть > > понимание - init дернул power-loss скриптик, в котором уже можно оценить > > масштаб проблемы, остановить нужное и принять решение - ждём восстановления > > или отключаемся. Или init дернул power-restored - когда поднимаем > > остановленное или в зависимости от - тупо перезагружаемся. > > Нет, через один SIGPWR это тоже всё решалось и решается, только вот скриптик > > будет разляпистее. > > Я все еще сомневаюсь, нужно ли здесь завязываться на init. > > Почему обычный демон не может сам запускать, в зависимости от ситуации, либо > power-loss, либо power-restored скрипты? В чем польза того, что в промежутке > между ними init и сигналы? > > Единственное преимущество от SIGPWR, которое я вижу, - это зафиксированный > API. Недостаток - API очень ограниченный. Даже если добавить еще сигналов, то > становится не очевидно, какому сигналу соответствует событие. /etc/inittab > как известная точка конфигурации для меня не убедительное достоинство, не > SysV init может использовать другой файл, чтобы назначать обработчики. > > Если скрипты запускаются напрямую демоном, который слушает SNMP, то событий > может быть несколько и со вполне нормальными именами. Главная проблема - > договориться о именах скриптов и их параметрах. Иначе будет головная боль с > тем, что у каждого производителя UPS они будут свои и не очень совместимые > между собой. Да, договариваться сложно, уходящий корнями в прошлое SIGPWR, > выглядит более знакомым и поэтому привлекательным. > >
