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

Victor Sudakov написал(а) к Eugene Grosbein в Apr 19 11:30:04 по местному времени:

Dear Eugene,

25 Apr 19 20:19, I wrote to eugen:

EG>>>> Я разве не упоминал в этом треде, что про штатное и дефолтное
EG>>>> поведение apcupsd не стоит даже думать, потому как оно заточено
EG>>>> под Linux?
VS>>> А зачем же мейнтейнеры порта заточили его как под линукс?

EG>> Это вопрос к маинтенеру, но думаю, что они ничего не затачивали,
EG>> тупо не заморачивались.

VS> Может я когда-нибудь напишу PR с предложениями, но сперва надо самому
VS> понять логику.

Написал PR, там сейчас интересное обсуждение с мейнтейнером идёт:
https://bugs.freebsd.org/bugzilla/sh....cgi?id=237600

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

Victor Sudakov написал(а) к Eugene Grosbein в May 19 13:24:28 по местному времени:

Dear Eugene,

28 Apr 19 11:30, I wrote to you:

VS> Написал PR, там сейчас интересное обсуждение с мейнтейнером идёт:
VS> https://bugs.freebsd.org/bugzilla/sh....cgi?id=237600

Вот некоторые выводы (дублирую из своего ЖЖ):

Алгоритм взаимодействия apcupsd с системой при её выключении не менялся уже 17 лет. По умолчанию apcupsd запускается с ключом --kill-on-powerfail, что означает: при исчерпании заряда аккумулятора в ИБП, послать ИБП команду "уснуть" и одновременно запустить процедуру doshutdown из /usr/local/etc/apcupsd/apccontrol. В ИБП обычно предусмотрена задержка (так называемый grace delay) 10-40 секунд исполнения команд "выключиться" и "уснуть". В этом месте начинается race: что случится раньше, shutdown успеет корректно завершиться или ИБП выключится?

В прежние времена, наверное, это всех устраивало, потому что выключение системы проходило быстро и shutdown успевал всё завершить до выключения питания. Хотя напомню, что значение по умолчанию rcshutdown_timeout="90" заведомо больше grace delay любого ИБП. Так что race condition никуда не девался на самом деле.

В нынешнее время с распространением виртуальных машин во время выключения хоста включено время выключения виртуалок, которое может быть весьма значительным. Я например устаналиваю rcshutdowntimeout="240" и kern.init_shutdowntimeout="300". Понятно, что в UPS grace delay не укладываемся точно.

Поэтому предлагаю новый алгоритм выключения системы посредством apcupsd, и открыл на эту тему ПР https://bugs.freebsd.org/bugzilla/sh....cgi?id=237600 Суть нового алгоритма:

Запускаем apcupsd с ключом --term-on-powerfail

apcupsd_enable="YES"
apcupsd_flags="--term-on-powerfail"

это значит после запуска процедуры shutdown и создания флага /var/run/powerfail apcupsd должен выйти и не путаться пока под ногами.

А в конце /etc/rc.shutdown вписываем строчку

test -f /var/run/powerfail && /usr/local/sbin/apcupsd --hibernate
или
test -f /var/run/powerfail && /usr/local/sbin/apcupsd --power-off

(кому как удобнее, в зависимости от требуемого поведения ИБП после восстановления питания).

Это означает, что только после отработки всех rc.d скриптов с параметром stop в ИБП будет послана команда "уснуть" или "выключиться" соответственно.

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

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

Доброго здоровьица тебе, Victor!

Wednesday May 01 2019 13:24, Victor Sudakov писал Eugene Grosbein:

VS> Это означает, что только после отработки всех rc.d скриптов с
VS> параметром stop в ИБП будет послана команда "уснуть" или "выключиться"
VS> соответственно.

Не знаю как в других линуксах, а у меня в gentoo вроде как искаропки похожий алгоритм. В shutdown скриптах последним перед halt выполняется killpower по флагу.

У этого алгоритма есть только один видимый мне трудно обоходимый но редкий недостаток. Если питание успело восстановиться после завершения apcupsd но до killpower (флаг powerfail некому удалить) то получаем кирпич который надо включать руками. Один раз мне на такой кейз удалось наступить.

Есть ещё один недостаток, при восстановлении питания после инициализации shutdown получаем включенный упс но выключенный комп. Обходится включением по таймеру или любому другому эвенту или патчем killpower скрипта на выполнение reboot при отсутствии powerfail флага.

С наилучшими пожеланиями, Семён.

... Хорошо там, где нас нет... (это не про фидошников)
--- GoldED+/LNX 1.1.5-b20170303 (Linux 4.1.12-gentoo iF6M10)

Eugene Grosbein написал(а) к Semen Panevin в May 19 00:12:00 по местному времени:

01 мая 2019, среда, в 15:11 NOVT, Semen Panevin написал(а):

SP> У этого алгоритма есть только один видимый мне трудно обоходимый но редкий
SP> недостаток. Если питание успело восстановиться после завершения apcupsd но до
SP> killpower (флаг powerfail некому удалить) то получаем кирпич который надо
SP> включать руками. Один раз мне на такой кейз удалось наступить.
SP> Есть ещё один недостаток, при восстановлении питания после инициализации
SP> shutdown получаем включенный упс но выключенный комп. Обходится включением по
SP> таймеру или любому другому эвенту или патчем killpower скрипта на выполнение
SP> reboot при отсутствии powerfail флага.

Все эти недостатки исчезают, если вместо shutdown делать ребут и
на ранней стадии загрузки проверять уровень заряда батареи
и приостанавливать загрузку, если уровень низок - до тех
пор, пока он не поднимется выше порога. Если питание успело восстановиться,
то батарея зарядится и загрузка просто продолжится.

Второго недостатка нет, потому что мы вообще никогда не выключаем UPS.
Он может только вырубиться сам из-за тотального разряда батареи и
комп отрубится, так и не смонтировав файловые системы
и не завершив загрузку, а потом включится как UPS снова подаст питание.

Eugene
--
Однажды, будучи ещё мальчишкой, я был на каникулах и прогуливался вдоль реки.
Я увидел выдру с выводком. Весьма умилительное зрелище, думаю, вы согласитесь
со мной. Выдра нырнула и поймала жирного лосося, которого она с трудом
выволокла на ствол полузатопленного дерева и принялась пожирать, разумеется,
заживо. Из распоротого брюха лосося вывалилась икра, о, я до сих пор помню
чудесный розовый цвет этих икринок, к которым тут же бросились маленькие выдры,
ссорясь между собой за лакомство. Чудо природы: мать и дети, пожирающие
мать и детей. Вот тогда я и познал впервые, что есть зло. Оно встроено в саму
природу вселенной.
--- slrn/1.0.3 (FreeBSD)

Semen Panevin написал(а) к Eugene Grosbein в May 19 19:53:22 по местному времени:

Доброго здоровьица тебе, Eugene!

Thursday May 02 2019 00:12, Eugene Grosbein писал Semen Panevin:

EG> Он может только вырубиться сам из-за тотального разряда батареи и
EG> комп отрубится, так и не смонтировав файловые системы
EG> и не завершив загрузку, а потом включится как UPS снова подаст
EG> питание.
Интересная идея. Я её подумаю...


С наилучшими пожеланиями, Семён.

... Незаменимых людей нет, но исключением стать хочется... (c)...
--- GoldED+/LNX 1.1.5-b20170303 (Linux 4.1.12-gentoo iF6M10)

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

Dear Semen,

01 May 19 17:11, you wrote to me:

VS>> Это означает, что только после отработки всех rc.d скриптов с
VS>> параметром stop в ИБП будет послана команда "уснуть" или
VS>> "выключиться" соответственно.

SP> Не знаю как в других линуксах, а у меня в gentoo вроде как искаропки
SP> похожий алгоритм. В shutdown скриптах последним перед halt выполняется
SP> killpower по флагу.

SP> У этого алгоритма есть только один видимый мне трудно обоходимый но
SP> редкий недостаток. Если питание успело восстановиться после завершения
SP> apcupsd но до killpower (флаг powerfail некому удалить) то получаем
SP> кирпич который надо включать руками. Один раз мне на такой кейз
SP> удалось наступить.

Насколько я понимаю, стандартный эхотажный способ запуска apcupsd этой проблемы также не решает.

SP> Есть ещё один недостаток, при восстановлении питания после
SP> инициализации shutdown получаем включенный упс но выключенный комп.

А это разве не тот же самый недостаток, что и описанный выше? По крайней мере мне тонкое различие между этими кейсами не видно.

SP> Обходится включением по таймеру или любому другому эвенту

Так наверное проще всего.

SP> или патчем
SP> killpower скрипта на выполнение reboot при отсутствии powerfail флага.

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

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

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

Dear eugen,

02 May 19 00:12, Eugene Grosbein wrote to Semen Panevin:

SP>> У этого алгоритма есть только один видимый мне трудно обоходимый
SP>> но редкий недостаток. Если питание успело восстановиться после
SP>> завершения apcupsd но до killpower (флаг powerfail некому
SP>> удалить) то получаем кирпич который надо включать руками. Один
SP>> раз мне на такой кейз удалось наступить. Есть ещё один
SP>> недостаток, при восстановлении питания после инициализации
SP>> shutdown получаем включенный упс но выключенный комп. Обходится
SP>> включением по таймеру или любому другому эвенту или патчем
SP>> killpower скрипта на выполнение reboot при отсутствии powerfail
SP>> флага.

EG> Все эти недостатки исчезают, если вместо shutdown делать ребут и
EG> на ранней стадии загрузки проверять уровень заряда батареи
EG> и приостанавливать загрузку, если уровень низок - до тех
EG> пор, пока он не поднимется выше порога. Если питание успело
EG> восстановиться, то батарея зарядится и загрузка просто продолжится.

Звучит красиво, но поскольку никто пока не предложил реализации этого в виде стартовых скриптов для FreeBSD (как минимум на уровне бета версии, которую можно было бы потестировать с реальной машиной и бесперебойником), оставляем этот алгоритм в области благопожеланий.

А я насколько хватило ума - настолько предложил простое и конкретное решение, которое устраняет хотя бы один - зато главный - race.

То, что это не реализовано в фирменных софтах от APC (лично я использовал под винду и под солярис) - тоже внушает определённые сомнения в реализуемости.

EG> Второго недостатка нет, потому что мы вообще никогда не выключаем UPS.
EG> Он может только вырубиться сам из-за тотального разряда батареи и
EG> комп отрубится, так и не смонтировав файловые системы
EG> и не завершив загрузку, а потом включится как UPS снова подаст
EG> питание.

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

Eugene Grosbein написал(а) к Victor Sudakov в May 19 04:16:50 по местному времени:

01 мая 2019, среда, в 22:30 NOVT, Victor Sudakov написал(а):

EG>> Все эти недостатки исчезают, если вместо shutdown делать ребут и
EG>> на ранней стадии загрузки проверять уровень заряда батареи
EG>> и приостанавливать загрузку, если уровень низок - до тех
EG>> пор, пока он не поднимется выше порога. Если питание успело
EG>> восстановиться, то батарея зарядится и загрузка просто продолжится.
VS> Звучит красиво, но поскольку никто пока не предложил реализации этого в виде
VS> стартовых скриптов для FreeBSD (как минимум на уровне бета версии, которую можно
VS> было бы потестировать с реальной машиной и бесперебойником), оставляем этот
VS> алгоритм в области благопожеланий.

Спасение утопающих дело рук самих утопающих.

Кратенько: кладём в /root специальный конфиг такого вида,
который заставляет apcupsd раз в секунду выдавать состояние
упса на stdout, если запустить его через apcupsd -bf /root/apcupsd.conf

## apcupsd.conf v1.1 ##
UPSNAME ES550-RS
UPSCABLE usb
UPSTYPE usb
UPSCLASS standalone
POLLTIME 1
STATTIME 1
LOCKFILE /tmp
EVENTSFILE /dev/null
STATFILE /dev/fd/1
LOGSTATS off
DATATIME 0

Среди выдаваемых строчек будет уровень заряда, такого формата:

BCНARGE : 100.0 Percent

И пишем код такого вида:

/root/bin/apcupsd -bf /root/apcupsd.conf | while read var colon val rest
do
case "$var" in
BCНARGE)
val=${val%.*}
[ "$val" -ge 10 ] && exit
esac ;;
done

Ну и ему надо оформляж сделать с REQUIRE: disks и BEFORE: fsck,
и положить в /etc/rc.d/

В /root/bin положить статически слинкованный бинарь apcupsd,
потому что к моменту запуска скрипта разделяемые библиотеки
ещё могут быть не доступны. Порешать проблему с LOCKFILE
одним из двух способов: apcupsd не стартует, если не может
создать лок и надо либо ему это оторвать в сорцах, либо
в скрипте создать небольшую tmpfs для /tmp в памяти
и перед выходом её удалить.

Eugene
--- slrn/1.0.3 (FreeBSD)

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

Dear eugen,

02 May 19 04:16, Eugene Grosbein wrote to me:

EG>>> Все эти недостатки исчезают, если вместо shutdown делать ребут и
EG>>> на ранней стадии загрузки проверять уровень заряда батареи
EG>>> и приостанавливать загрузку, если уровень низок - до тех
EG>>> пор, пока он не поднимется выше порога. Если питание успело
EG>>> восстановиться, то батарея зарядится и загрузка просто
EG>>> продолжится.
VS>> Звучит красиво, но поскольку никто пока не предложил реализации
VS>> этого в виде стартовых скриптов для FreeBSD (как минимум на
VS>> уровне бета версии, которую можно было бы потестировать с
VS>> реальной машиной и бесперебойником), оставляем этот алгоритм в
VS>> области благопожеланий.

EG> Спасение утопающих дело рук самих утопающих.

Спасибо за пример.

EG> В /root/bin положить статически слинкованный бинарь apcupsd,
EG> потому что к моменту запуска скрипта разделяемые библиотеки
EG> ещё могут быть не доступны. Порешать проблему с LOCKFILE
EG> одним из двух способов: apcupsd не стартует, если не может
EG> создать лок и надо либо ему это оторвать в сорцах, либо
EG> в скрипте создать небольшую tmpfs для /tmp в памяти
EG> и перед выходом её удалить.

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

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

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

Доброго здоровьица тебе, Victor!

Thursday May 02 2019 00:22, Victor Sudakov писал Semen Panevin:

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

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

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

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

depend() {
need mount-ro
}

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

С наилучшими пожеланиями, Семён.

... Век живи, век учись!
--- GoldED+/LNX 1.1.5-b20170303 (Linux 4.1.12-gentoo iF6M10)