@MSGID: <HiA7w-bTkY-3@gated-at.bofh.it> da90cb1a
@REPLY: <HiaG5-bCEH-5@gated-at.bofh.it> 124cda31
@REPLYADDR Max Nikulin <manikulin@gmail.com>
@REPLYTO 2:5075/128 Max Nikulin
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: <HiA7w-bTkY-3@gated-at.bofh.it>
@RFC-References: <HhQxH-bpWE-3@gated-at.bofh.it>
<HhSSR-brtY-3@gated-at.bofh.it> <HiaG5-bCEH-5@gated-at.bofh.it>
@TZUTC: 0200
@PID: Mozilla/5.0 (X11; Linux x86_64; rv:102.0)
Gecko/20100101 Thunderbird/102.15.1
@TID: FIDOGATE-5.12-ge4e8b94
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_RUNLE
VELS
>> я перестал понимать, куда его дальше-то расширять? Вроде наоборот хотят
>> сузить, выкинув /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 сигнала и остановились на варианте, который сейчас 
выглядит несколько вычурным.

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

С сокетами проще. Если есть утилита и библиотека, которые могут слать 
нужные сообщения, и процесс их может правильно обработать, то это лучше, 
чем сигналы. Мне такой вариант нравится больше.

А вообще, можно и полностью избавить init от кода, специфичного для 
обработки событий питания. Все равно это сводится к более общему и 
универсальному интерфейсу "запустить команду с параметрами". Вот пусть 
демон UPS и просит выполнить один из вариантов "powerfail start", 
"powerfail now", "powerfail stop" (ну или что-то похожее) прямым текстом 
без эфвемизмов вроде нумерованных сигналов.

>> On 19/09/2023 14:00, Andrey Jr. Melnikov wrote:
>>> Я бы понял, если бы он сделал 3 сигнала SIGPWR для информирования о том,
>>> что питание пропало, SIGRTMIN+x1 для информирования о том, что питание
>>> появилось обратно и SIGRTMIN+x2 - для emergency power shutdown - был бы
>>> разговор о прогрессе и удобстве.
> 
>> Это про systemd было.
> Увы, в systemd тоже этого не сделали.

Я бы еще понял ругань, что в systemd отломали старые интерфейсы. С 
ininctl вообще какой-то абсурд. Он сообщения понимает, но просто плюется 
в логи, что обновляйте свой UPS.

Cигналов в systemd как раз выше крыши:

On 19/09/2023 14:00, Andrey Jr. Melnikov wrote:
> Да, задизайнить
> SIGRTMIN+4 в poweroff и SIGRTMIN+14 в immediate poweroff - смог

Ну вот 2 сигнала уже есть. Точнее там другая интерпретация SIGPWR: 
готовьтесь, питание может кончится, а запускаемые скрипты уже могут 
что-то делать, хоть тот же powerstatus читать.

Если питание вернулось, то для этого есть

SIGRTMIN+0
   Enters default mode, starts the default.target unit.
   This is mostly equivalent to systemctl isolate default.target.

Ну просто мечта любителя сигналов.
 --- Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.15.1
 * Origin: linux.* mail to news gateway (2:5075/128)
SEEN-BY: 221/6 301/1 467/888 5001/100 5005/49
5015/255 5019/40 5020/715 848
SEEN-BY: 5020/1042 4441 12000 5030/49 1081 5061/133
5075/37 128 6078/80
@PATH: 5075/128 5020/1042 4441