Как правильно готовить apcupsd

Victor Sudakov написал(а) к Semen Panevin в May 19 13:14:22 по местному времени:

Dear Semen,

02 May 19 08:23, you wrote to me:

SP>>> Есть ещё один недостаток, при восстановлении питания после
SP>>> инициализации shutdown получаем включенный упс но выключенный
SP>>> комп.
VS>> А это разве не тот же самый недостаток, что и описанный выше? По
VS>> крайней мере мне тонкое различие между этими кейсами не видно.
SP> При включенном упсе комп может включиться по какому-нибудь эвенту,
SP> например по таймеру. А в предыдущем случае мы получаем выключеннйы
SP> упс, который сам включаться не умеет, нету у него таймера включения
SP> (ну может у каких-то и есть, но у моего нет).

Теперь понятно.

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

Фирменный софт от APC под Винду и Солярис тоже AFAIK этим вопросом не заморачивается. Под Солярис вообще был смешной, если его инсталлятор не находил Java нужной ему и только ему версии, он ставил собственную и из неё работал. Но умел при этом не больше чем apcupsd.

VS>> Не понял. В предлагаемой мной схеме нет killpower скрипта. Если
VS>> ты про генту, то ты про тот самый скрипт, который выполняется
VS>> последним перед halt? Можно посмотреть на него?

SP> # cat /etc/init.d/apcupsd.powerfail
SP> #!/sbin/openrc-run
SP> # Copyright 2009 Gentoo Foundation
SP> # Distributed under the terms of the GNU General Public License v2

SP> description='Signal the UPS to kill power in a power failure
SP> condition'

SP> depend() {
SP> need mount-ro
SP> }

SP> start() {
SP> if [ "$(runlevel | cut -d' ' -f2)" = "0" -a -f
SP> /etc/apcupsd/powerfail ] ; then
SP> ebegin 'Signaling UPS to kill power'
SP> /sbin/apcupsd --killpower
SP> eend $?
SP> fi
SP> }

Спасибо. Получается что я практически линуксовый велосипед изобрел со своим PR. Ну да ничего, если бы в FreeBSD-шный порт сабжа с запозданием на десятилетия попала хотя бы эта логика, это уже был бы громадный шаг вперед.

А ещё про gentoo - с каким ключом apcupsd работает там в дежурном режиме (слежение за ИБП)?

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Eugene Grosbein написал(а) к Victor Sudakov в May 19 15:59:37 по местному времени:

02 мая 2019, четверг, в 09:22 NOVT, Victor Sudakov написал(а):

VS> IMНO такое точно не примут в качестве замены нынешнему состоянию дел с портом.
VS> Слишком всё нештатно.

А причём тут "примут"? Далеко не все локальные особенности нужны
в основном дереве.

Eugene
--- slrn/1.0.3 (FreeBSD)

Victor Sudakov написал(а) к eugen в May 19 22:15:52 по местному времени:

Dear eugen,

02 May 19 15:59, Eugene Grosbein wrote to me:

VS>> IMНO такое точно не примут в качестве замены нынешнему состоянию
VS>> дел с портом. Слишком всё нештатно.

EG> А причём тут "примут"? Далеко не все локальные особенности нужны
EG> в основном дереве.

Это не локальная особенность, я поставил себе сверхзадачу добиться, чтобы довели интеграцию sysutils/apcupsd в систему хотя бы до уровня Линукса (убрали главный race).

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Victor Sudakov написал(а) к Semen Panevin в May 19 22:22:30 по местному времени:

Dear Semen,

02 May 19 08:23, you wrote to me:

[dd]
VS>> последним перед halt? Можно посмотреть на него?

SP> # cat /etc/init.d/apcupsd.powerfail

Да, а чем обеспечивается, что данный скрипт запускается всегда последним перед halt?

SP> #!/sbin/openrc-run
SP> # Copyright 2009 Gentoo Foundation
SP> # Distributed under the terms of the GNU General Public License v2

SP> description='Signal the UPS to kill power in a power failure
SP> condition'

SP> depend() {
SP> need mount-ro
SP> }

SP> start() {
SP> if [ "$(runlevel | cut -d' ' -f2)" = "0" -a -f
SP> /etc/apcupsd/powerfail ] ; then
SP> ebegin 'Signaling UPS to kill power'
SP> /sbin/apcupsd --killpower
SP> eend $?
SP> fi
SP> }


Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Eugene Grosbein написал(а) к Victor Sudakov в May 19 00:33:39 по местному времени:

02 мая 2019, четверг, в 20:15 NOVT, Victor Sudakov написал(а):

VS>>> IMНO такое точно не примут в качестве замены нынешнему состоянию
VS>>> дел с портом. Слишком всё нештатно.
EG>> А причём тут "примут"? Далеко не все локальные особенности нужны
EG>> в основном дереве.
VS> Это не локальная особенность, я поставил себе сверхзадачу добиться, чтобы
VS> довели интеграцию sysutils/apcupsd в систему хотя бы до уровня Линукса (убрали
VS> главный race).

Сделать как в Linux так себе "сверхзадача". Надеюсь, ты понимаешь,
что уменьшить окно для гонки это не значит "убрать race".

Eugene
--
А ученый уподобляется обученному слону, которого погонщик поставил перед
преградой. Он пользуется силой разума, как слон --- силой мышц, подчиняясь
приказу. Это необычайно удобно: ученый отныне готов на все, так как ни за
что уже не отвечает.
--- slrn/1.0.3 (FreeBSD)

Victor Sudakov написал(а) к eugen в May 19 23:54:42 по местному времени:

Dear eugen,

03 May 19 00:33, Eugene Grosbein wrote to me:

VS>>>> IMНO такое точно не примут в качестве замены нынешнему
VS>>>> состоянию дел с портом. Слишком всё нештатно.
EG>>> А причём тут "примут"? Далеко не все локальные особенности нужны
EG>>> в основном дереве.
VS>> Это не локальная особенность, я поставил себе сверхзадачу
VS>> добиться, чтобы довели интеграцию sysutils/apcupsd в систему хотя
VS>> бы до уровня Линукса (убрали главный race).

EG> Сделать как в Linux так себе "сверхзадача".

Я только за, если кто-то попробует сделать (и главное протолкнуть в mainstream) более совершенное решение, чем в Linux.

EG> Надеюсь, ты понимаешь,
EG> что уменьшить окно для гонки это не значит "убрать race".

Я просто объективно (надеюсь) оцениваю риски. Линуксовый race исключает риск потери данных, и оставляет только риск невключения сервера, причем этот риск весьма маловероятный.

В существующем положении в sysutils/apcupsd присутствует риск потери данных.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Eugene Grosbein написал(а) к Victor Sudakov в May 19 01:49:40 по местному времени:

02 мая 2019, четверг, в 21:54 NOVT, Victor Sudakov написал(а):

VS> В существующем положении в sysutils/apcupsd присутствует риск потери данных.

Тебя устроит и сможешь ли ты протестировать такое решение:

1) из штатного /etc/rc.shutdown будет вызываться некий скрипт
типа /etc/rc.shutdown.final (если он существует),
сразу после строчки: # Insert other shutdown procedures here
что гарантирует его запуск "в самом конце";

2) в стартовый скрипт порта apcupsd добавляем что-то вроде:

extra_commands="killpower"
killpowercmd="apcupsdkillpower"

apcupsd_killpower() {
apcupsd --killpower или как там надо
}

3) ты создаёшь себе скрипт /etc/rc.shutdown.final
с одной командой service apcpuspd killpower,
которую будешь вызывать, если аргумент $1 скрипта
не reboot (что значит, что система просто ребутится)
и не single (что значит, что система переходит в single user mode).

Если есть лучшее имя вместо rc.shutdown.final -
приложения принимаются. К сожалению, имя
/etc/rc.shutdown.local уже занято и семантика у него
другая, legacy.

Eugene
--
Господа Действительного Положения Вещей предохраняют себя от голода своим
богатством, от общественного мнения - тайной и анонимностью,
от частной критики - законами против клеветы и тем, что средства связи
находятся в их распоряжении. (Норберт Винер)
--- slrn/1.0.3 (FreeBSD)

Eugene Grosbein написал(а) к Eugene Grosbein в May 19 01:50:51 по местному времени:

03 мая 2019, пятница, в 00:49 NOVT, Eugene Grosbein написал(а):

EG> Если есть лучшее имя вместо rc.shutdown.final -
EG> приложения принимаются. К сожалению, имя
EG> /etc/rc.shutdown.local уже занято и семантика у него
EG> другая, legacy.

s/приложения/предложения/

Eugene
--- slrn/1.0.3 (FreeBSD)

Victor Sudakov написал(а) к eugen в May 19 09:30:12 по местному времени:

Dear eugen,

03 May 19 01:49, Eugene Grosbein wrote to me:

VS>> В существующем положении в sysutils/apcupsd присутствует риск
VS>> потери данных.

EG> Тебя устроит и сможешь ли ты протестировать такое решение:

Смогу.

EG> 1) из штатного /etc/rc.shutdown будет вызываться некий скрипт
EG> типа /etc/rc.shutdown.final (если он существует),
EG> сразу после строчки: # Insert other shutdown procedures here
EG> что гарантирует его запуск "в самом конце";

У меня в этом месте сейчас просто
test -f /var/run/powerfail && /usr/local/sbin/apcupsd -k

EG> 2) в стартовый скрипт порта apcupsd добавляем что-то вроде:

EG> extra_commands="killpower"
EG> killpowercmd="apcupsdkillpower"

EG> apcupsd_killpower() {
EG> apcupsd --killpower или как там надо
EG> }

А параметр ${apcupsd_flags="--kill-on-powerfail"} в стартовом скрипте порта тоже меняем?

EG> 3) ты создаёшь себе скрипт /etc/rc.shutdown.final
EG> с одной командой service apcpuspd killpower,
EG> которую будешь вызывать, если аргумент $1 скрипта
EG> не reboot (что значит, что система просто ребутится)
EG> и не single (что значит, что система переходит в single user mode).

EG> Если есть лучшее имя вместо rc.shutdown.final -
EG> приложения принимаются. К сожалению, имя
EG> /etc/rc.shutdown.local уже занято и семантика у него
EG> другая, legacy.

Я тоже не придумал, как гарантировать скрипту из rc.d, что он будет выполнен последним при shutdown.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Eugene Grosbein написал(а) к Victor Sudakov в May 19 17:59:46 по местному времени:

03 мая 2019, пятница, в 07:30 NOVT, Victor Sudakov написал(а):

VS>>> В существующем положении в sysutils/apcupsd присутствует риск
VS>>> потери данных.
EG>> Тебя устроит и сможешь ли ты протестировать такое решение:
VS> Смогу.
EG>> 1) из штатного /etc/rc.shutdown будет вызываться некий скрипт
EG>> типа /etc/rc.shutdown.final (если он существует),
EG>> сразу после строчки: # Insert other shutdown procedures here
EG>> что гарантирует его запуск "в самом конце";
VS> У меня в этом месте сейчас просто
VS> test -f /var/run/powerfail && /usr/local/sbin/apcupsd -k
EG>> 2) в стартовый скрипт порта apcupsd добавляем что-то вроде:
EG>> extra_commands="killpower"
EG>> killpowercmd="apcupsdkillpower"
EG>> apcupsd_killpower() {
EG>> apcupsd --killpower или как там надо
EG>> }
VS> А параметр ${apcupsd_flags="--kill-on-powerfail"} в стартовом скрипте порта
VS> тоже меняем?

Изменение дефолтного поведения порта - преррогатива его майнтейнера.
Ты разве не можешь себе это поменять в /etc/rc.conf сам?

EG>> 3) ты создаёшь себе скрипт /etc/rc.shutdown.final
EG>> с одной командой service apcpuspd killpower,
EG>> которую будешь вызывать, если аргумент $1 скрипта
EG>> не reboot (что значит, что система просто ребутится)
EG>> и не single (что значит, что система переходит в single user mode).
EG>> Если есть лучшее имя вместо rc.shutdown.final -
EG>> приложения принимаются. К сожалению, имя
EG>> /etc/rc.shutdown.local уже занято и семантика у него
EG>> другая, legacy.
VS> Я тоже не придумал, как гарантировать скрипту из rc.d, что он будет выполнен
VS> последним при shutdown.

Я же написал, как, в квоте. Команда service apcupsd killpower
как раз и вызывает скрипт из rc.d с параметром killpower
гарантировано последним при shutdown, если эту команду
вставить в /etc/rc.shutdown.final

Eugene
--- slrn/1.0.3 (FreeBSD)