Max Nikulin <maniku...@gmail.com> wrote:
> On 26/09/2023 14:19, Andrey Jr. Melnikov wrote:
> > Max Nikulin wrote:
> >
> >> https://manpages.debian.org/bookworm/sysvinit-core/init.8.en.html#CHANGING_RUNLEVELS
> >> я перестал понимать, куда его дальше-то расширять? Вроде наоборот хотят
> >> сузить, выкинув /etc/powerstatus, по которому определяется, какой из 3
> >> скриптов запускать по SIGPWR
> > Даа, читал ты его явно по диагонали.

> Тем не менее единственное новое, что я увидел в пересказе, - это 
> /var/run/powerstatus, что не особенно принципиально (из разряда мелочь, 
> но приятно).

> >>> L(OW)
> >>>      The power is failing and the UPS has a low battery. Execute the
> >>>      powerfailnow entries.
> >> Я не в восторге от такого решения, но и предлагавшиеся 3 сигнала, с моей
> >> точки зрения, не лучше.
> > Т.е. с твоей точки зраения один signal(1, SIGRTMIN+x) хуже чем вся эта
> > пляска вокруг файликов с сигналами и FIFO?

> Я думаю, мы ни до чего не договоримся, да и не важно, ведь ни на что это 
> не повлияет.
А чего тогда разговаривать...

> Да, у меня прямо противоположное мнение о том, какой интерфейс лучше 
> подходит. Перенумеровать все возможные события - затея гиблая, люди в 
> них начнут путаться. Надо ведь еще и имена им дать. Поэтому я против 3-х 
> сигналов.

> Я думаю, что когда люди выбрали один SIGPWR + /etc/powerstatus, они 
> рассматривали 3 сигнала и остановились на варианте, который сейчас 
> выглядит несколько вычурным.
Когда они его выбирали - про SIGRTMIN ещё даже никто и не думал. SIGRTMIN
появится только в POSIX 1003.1b а это 1993 год. Собственно по этому там
такой изощрённый мультиплексор с файликом - сигнал один, а передать
состоняие надо больше чем одно.

> Послать-то сигнал может и просто, а вот правильно поймать уже некоторое 
> искусство. Чинить обработчики сигналов - трудоемкий процесс. За это я 
> сигналы не люблю.
Вот и не надо перекладывать свои "люблю-нелюблю" на всех. Сигналы -
хорошее, правильное асинхронное средство донести до процесса необходимую
информацию. 

> С сокетами проще. Если есть утилита и библиотека, которые могут слать 
> нужные сообщения, и процесс их может правильно обработать, то это лучше, 
> чем сигналы. Мне такой вариант нравится больше.
Проще? Создать сокет, открыть сокет, крутить select() в цикле, обрабатывать
ошибки, прочитать сокет (если прочитается), закрыть сокет.. и это все вместо 
одного signal handler?

Нее, всё, больше с тобой разговривать не о чем, если ты совершенно не
понимаешь условия задачи. Ты можешь во все запускаемые скрипты добавлять
опрос ups - если тебе так удобно. Но мне - удобнее иметь три отдельных
сигнала, три отдельных точки запуска - в которых в зависиомости от типа UPS
будут или не будут отключатся сетевы интерфесы, система будет уходить в
suspend-to-disk или полный power-off.

Ответить