#1
|
|||
|
|||
Как правильно готовить apcupsd
Victor Sudakov написал(а) к All в Apr 19 18:42:28 по местному времени:
Dear All, Это уже вроде как избитый вопрос, но погуглил и не нашёл подходящих советов. По умолчанию предполагается, что установленный из портов сабж запускается как "/usr/local/sbin/apcupsd --kill-on-powerfail", в этом случае сабж запускает shutdown системы и одновременно посылает ИБП сигнал о выключении питания. ИБП предусматривает некую отсрочку примерно 30 секунд, за это время система должна успеть отработать shutdown, и тут как раз питание пропадает. Всё бы хорошо, но виндовые сервера в bhyve выключаются долго, несколько минут проходит между "vm stopall" и их выключением. В полминутную отсрочку это не укладывается. Как лучше поступить? 1. Запускать apcupsd без ключей, пусть он шатдаунит систему, но питание ИБП не отключает никогда? В этом случае есть риск не отследить внезапное возвращение питания и остаться выключенным. 2. Поставить большой KILLDELAY в apcupsd.conf? Но тогда есть шанс, что shutdown (в смысле rc) прибьёт apcupsd раньше, чем он успеет послать killpower. И мы тогда получаем сценарий 1. Ну и фиг с ним, может быть? 3. ??? Victor Sudakov, VAS4-RIPE, VAS47-RIPN --- GoldED+/BSD 1.1.5-b20160322-b20160322 |
#2
|
|||
|
|||
Re: Как правильно готовить apcupsd
Eugene Grosbein написал(а) к Victor Sudakov в Apr 19 10:22:22 по местному времени:
21 апр. 2019, воскресенье, в 16:42 NOVT, Victor Sudakov написал(а): VS> Это уже вроде как избитый вопрос, но погуглил и не нашёл подходящих советов. По VS> умолчанию предполагается Не надо смотреть на умолчания, потому что они подразумевают определенное поведение операционной системы при шатдауне, которое в Linux сильно другое. И у меня дежавю - мы это точно тут уже обсуждали. Нашел: > 15 апр. 2017, суббота, в 16:10 NOVT, Victor Sudakov написал(а): > > VS> Приобрел Back-UPS XS 650CI для дома, поставил сабж. Сабж по умолчанию > VS> запускается с ключом --kill-on-powerfail, причем grace period у этого ИБП не > VS> настраивается, но и не нулевой. > VS> Эксперимент показал, что фря (и виртуалки в bhyve) в общем-то успевают > VS> отработать "shutdown -h" до того момента, когда ИБП отключает питание компу. > VS> Но не хотелось бы устраивать такой race condition. Меня бы устроило, если бы > VS> комп просто ушел в shutdown по достижении MINUTES или BATTERYLEVEL, а ИБП > VS> работал до последнего, пока аккумулятор не кончится. Может есть какой-то более > VS> правильный способ готовить сабж? > > Обычно рекомендуется в момент X вместо отключения выполнять ребут > и во время загрузки очень рано - ещё до монтирования файловых систем в r/w - > проверять наличие питания на входе и уровень заряда батарей и делать паузу, > пока условие не выполнится. Если питание так и не вернется - всё умрёт > когда кончится аккумулятор, как тебе и надо, а если вернется - загрузка > продолжится с подзаряженными аккумуляторами и если питание опять пропадёт > во время загрузки, система не сдохнет ВНЕЗАПНО с уже смонтированными fs > на полдороге к полному старту. При использовании транзакционной ZFS монтирование r/o не настолько важно (хотя и полезно), но вот старт сервисов, которые вовсе не обязательно транзакционно работают со своими данными (а тем более, виртуалок), всё так же лучше выполнять с достаточным процентом заряда батареи. Eugene --- slrn/1.0.3 (FreeBSD) |
#3
|
|||
|
|||
Re: Как правильно готовить apcupsd
Eugene Grosbein написал(а) к Victor Sudakov в Apr 19 10:31:40 по местному времени:
21 апр. 2019, воскресенье, в 16:42 NOVT, Victor Sudakov написал(а): VS> Это уже вроде как избитый вопрос, но погуглил и не нашёл подходящих советов. По VS> умолчанию предполагается, что установленный из портов сабж запускается как VS> "/usr/local/sbin/apcupsd --kill-on-powerfail", в этом случае сабж запускает VS> shutdown системы и одновременно посылает ИБП сигнал о выключении питания. ИБП VS> предусматривает некую отсрочку примерно 30 секунд, за это время система должна VS> успеть отработать shutdown, и тут как раз питание пропадает. VS> Всё бы хорошо, но виндовые сервера в bhyve выключаются долго, несколько минут VS> проходит между "vm stopall" и их выключением. В полминутную отсрочку это не VS> укладывается. Конкретно эта проблема должна решаться элементарно: запретить apcupsd гасить UPS по собственной инициативе и положить в rc.d свой скрипт, который будет запускаться последним при шатдауне, когда виртуалки уже погашены, и если в логе есть указание на то, что шатдаун начат из-за упса - выдавать ему команду на отключение питания через 30 секунд, за которые ядро должно успеть погасить всё оставшееся. Решение так себе, потому что race остаётся. Eugene -- Устав от вечных упований, Устав от радостных пиров --- slrn/1.0.3 (FreeBSD) |
#4
|
|||
|
|||
Как правильно готовить apcupsd
Victor Sudakov написал(а) к eugen в Apr 19 21:44:28 по местному времени:
Dear eugen, 22 Apr 19 10:31, Eugene Grosbein wrote to me: VS>> Это уже вроде как избитый вопрос, но погуглил и не нашёл VS>> подходящих советов. По умолчанию предполагается, что VS>> установленный из портов сабж запускается как VS>> "/usr/local/sbin/apcupsd --kill-on-powerfail", в этом случае сабж VS>> запускает shutdown системы и одновременно посылает ИБП сигнал о VS>> выключении питания. ИБП предусматривает некую отсрочку примерно VS>> 30 секунд, за это время система должна успеть отработать VS>> shutdown, и тут как раз питание пропадает. Всё бы хорошо, но VS>> виндовые сервера в bhyve выключаются долго, несколько минут VS>> проходит между "vm stopall" и их выключением. В полминутную VS>> отсрочку это не укладывается. EG> Конкретно эта проблема должна решаться элементарно: запретить apcupsd EG> гасить UPS по собственной инициативе То есть запускать его совсем без ключей? EG> и положить в rc.d EG> свой скрипт, который будет запускаться последним при шатдауне, А как обеспечить, чтобы определенный скрипт запускался последним при шатдауне? EG> когда виртуалки уже погашены, и если в логе есть указание на то, EG> что шатдаун начат из-за упса - выдавать ему команду на отключение EG> питания через 30 секунд, за которые ядро должно успеть погасить EG> всё оставшееся. Решение так себе, потому что race остаётся. IMНO это практически годное решение. В отличие от изложенного в соседнем письме (с ребутом вместо шатдауна), которое совсем уж неканоническое и вряд ли кем-то на практике реализовалось. Я видимо потому и забыл его суть. Victor Sudakov, VAS4-RIPE, VAS47-RIPN --- GoldED+/BSD 1.1.5-b20160322-b20160322 |
#5
|
|||
|
|||
Re: Как правильно готовить apcupsd
Eugene Grosbein написал(а) к Victor Sudakov в Apr 19 15:05:28 по местному времени:
22 апр. 2019, понедельник, в 19:44 NOVT, Victor Sudakov написал(а): VS>>> Это уже вроде как избитый вопрос, но погуглил и не нашёл VS>>> подходящих советов. По умолчанию предполагается, что VS>>> установленный из портов сабж запускается как VS>>> "/usr/local/sbin/apcupsd --kill-on-powerfail", в этом случае сабж VS>>> запускает shutdown системы и одновременно посылает ИБП сигнал о VS>>> выключении питания. ИБП предусматривает некую отсрочку примерно VS>>> 30 секунд, за это время система должна успеть отработать VS>>> shutdown, и тут как раз питание пропадает. Всё бы хорошо, но VS>>> виндовые сервера в bhyve выключаются долго, несколько минут VS>>> проходит между "vm stopall" и их выключением. В полминутную VS>>> отсрочку это не укладывается. EG>> Конкретно эта проблема должна решаться элементарно: запретить apcupsd EG>> гасить UPS по собственной инициативе VS> То есть запускать его совсем без ключей? Я не использую apcupsd для управления серверами, про ключи не подскажу. У меня apcupsd используется только для рабочих станций и десктопа. Для серверной у меня есть скрипт, который опрашивает плату управления серверного UPS по SNMP и если оно индицирует отсутствие входного питания и уровень заряда батарей ниже порога, то гасит часть железа по ssh, чтобы дать другому шанс дожить без гашения вообще (несколько часов). EG>> и положить в rc.d EG>> свой скрипт, который будет запускаться последним при шатдауне, VS> А как обеспечить, чтобы определенный скрипт запускался последним при шатдауне? Mon, 17 Apr 2017 16:33:00 +0700: > Тогда я наверное могу вставить 'apcupsd --power-off' в конец /etc/rc.shutdown, > а из режима мониторинга убрать ключ --kill-on-powerfail, и получится то же > самое, что у тебя. Т.е. race condition останется, но будет происходить > значительно позже, уже после остановки всех демонов. > ЗЫ --power-off, а не --killpower, потому что мне не надо, чтобы после включения > питания ИБП проснулся: машинка всё равно запускается руками. > > Victor Sudakov, VAS4-RIPE, VAS47-RIPN Я, правда, предпочитаю просто обозвать скрипт 000.something, чтобы он в обратном порядке гашения получился раньше. Можно ещё в стартовый скрипт бихайва добавить зависимость от 000.something, чтобы при загрузке у него порядок был позже, а при выключении раньше. Полно вариантов. Eugene -- Комбинация заискивания, подкупа и устрашения заставит молодого ученого работать над управляемыми снарядами или атомной бомбой. (Норберт Винер) --- slrn/1.0.3 (FreeBSD) |
#6
|
|||
|
|||
Как правильно готовить apcupsd
Victor Sudakov написал(а) к eugen в Apr 19 22:23:18 по местному времени:
Dear eugen, 23 Apr 19 15:05, Eugene Grosbein wrote to me: VS>>>> Это уже вроде как избитый вопрос, но погуглил и не нашёл VS>>>> подходящих советов. По умолчанию предполагается, что VS>>>> установленный из портов сабж запускается как VS>>>> "/usr/local/sbin/apcupsd --kill-on-powerfail", в этом случае VS>>>> сабж запускает shutdown системы и одновременно посылает ИБП VS>>>> сигнал о выключении питания. ИБП предусматривает некую отсрочку VS>>>> примерно 30 секунд, за это время система должна успеть VS>>>> отработать shutdown, и тут как раз питание пропадает. Всё бы VS>>>> хорошо, но виндовые сервера в bhyve выключаются долго, VS>>>> несколько минут проходит между "vm stopall" и их выключением. В VS>>>> полминутную отсрочку это не укладывается. EG>>> Конкретно эта проблема должна решаться элементарно: запретить EG>>> apcupsd гасить UPS по собственной инициативе VS>> То есть запускать его совсем без ключей? EG> Я не использую apcupsd для управления серверами, про ключи не EG> подскажу. У меня apcupsd используется только для рабочих станций и EG> десктопа. А на них он как запускается у тебя? VS>> А как обеспечить, чтобы определенный скрипт запускался последним VS>> при шатдауне? EG> Mon, 17 Apr 2017 16:33:00 +0700: >> Тогда я наверное могу вставить 'apcupsd --power-off' в конец >> /etc/rc.shutdown, Ну да, я когда-то думал об этом, но это ведь нештатный способ? >> а из режима мониторинга убрать ключ >> --kill-on-powerfail, и получится то же самое, что у тебя. Т.е. race >> condition останется, но будет происходить значительно позже, уже >> после остановки всех демонов. >> ЗЫ --power-off, а не --killpower, потому что мне не надо, чтобы >> после включения питания ИБП проснулся: машинка всё равно запускается >> руками. >> >> Victor Sudakov, VAS4-RIPE, VAS47-RIPN EG> Я, правда, предпочитаю просто обозвать скрипт 000.something, EG> чтобы он в обратном порядке гашения получился раньше. EG> Можно ещё в стартовый скрипт бихайва добавить зависимость от EG> 000.something, чтобы при загрузке у него порядок был позже, а при EG> выключении раньше. EG> Полно вариантов. А штатный для rcNG является какой вариант обязательного запуска скрипта последним? Victor Sudakov, VAS4-RIPE, VAS47-RIPN --- GoldED+/BSD 1.1.5-b20160322-b20160322 |
#7
|
|||
|
|||
Re: Как правильно готовить apcupsd
Eugene Grosbein написал(а) к Victor Sudakov в Apr 19 04:32:46 по местному времени:
23 апр. 2019, вторник, в 20:23 NOVT, Victor Sudakov написал(а): EG>> Я не использую apcupsd для управления серверами, про ключи не EG>> подскажу. У меня apcupsd используется только для рабочих станций и EG>> десктопа. VS> А на них он как запускается у тебя? Дефолтно. VS>>> А как обеспечить, чтобы определенный скрипт запускался последним VS>>> при шатдауне? EG>> Mon, 17 Apr 2017 16:33:00 +0700: >>> Тогда я наверное могу вставить 'apcupsd --power-off' в конец >>> /etc/rc.shutdown, VS> Ну да, я когда-то думал об этом, но это ведь нештатный способ? Я разве не упоминал в этом треде, что про штатное и дефолтное поведение apcupsd не стоит даже думать, потому как оно заточено под Linux? EG>> Я, правда, предпочитаю просто обозвать скрипт 000.something, EG>> чтобы он в обратном порядке гашения получился раньше. EG>> Можно ещё в стартовый скрипт бихайва добавить зависимость от EG>> 000.something, чтобы при загрузке у него порядок был позже, а при EG>> выключении раньше. EG>> Полно вариантов. VS> А штатный для rcNG является какой вариант обязательного запуска скрипта VS> последним? По-моему, такого и быть не может в такой формулировке: если ты сделаешь два "последних" скрипта, который из них реально будет последним? :-) Я бы просто сделал скрипт с REQUIRE: SERVERS и назвал его 000.something. Eugene --- slrn/1.0.3 (FreeBSD) |
#8
|
|||
|
|||
Как правильно готовить apcupsd
Victor Sudakov написал(а) к eugen в Apr 19 10:15:46 по местному времени:
Dear eugen, 24 Apr 19 04:32, Eugene Grosbein wrote to me: EG>>> Я не использую apcupsd для управления серверами, про ключи не EG>>> подскажу. У меня apcupsd используется только для рабочих станций EG>>> и десктопа. VS>> А на них он как запускается у тебя? EG> Дефолтно. Дома у меня тоже дефолтно и всё успевает погаснуть. VS>>>> А как обеспечить, чтобы определенный скрипт запускался VS>>>> последним при шатдауне? EG>>> Mon, 17 Apr 2017 16:33:00 +0700: >>>> Тогда я наверное могу вставить 'apcupsd --power-off' в конец >>>> /etc/rc.shutdown, VS>> Ну да, я когда-то думал об этом, но это ведь нештатный способ? EG> Я разве не упоминал в этом треде, что про штатное и дефолтное EG> поведение apcupsd не стоит даже думать, потому как оно заточено под EG> Linux? А зачем же мейнтейнеры порта заточили его как под линукс? Может иначе нельзя или трудно придумать штатное решение? Я бы написал PR, но не представляю альтернативу существующему способу. Дописывание чего-то в rc.shutdown они, я уверен, даже рассматривать не будут. EG>>> Я, правда, предпочитаю просто обозвать скрипт 000.something, EG>>> чтобы он в обратном порядке гашения получился раньше. EG>>> Можно ещё в стартовый скрипт бихайва добавить зависимость от EG>>> 000.something, чтобы при загрузке у него порядок был позже, а EG>>> при выключении раньше. Полно вариантов. VS>> А штатный для rcNG является какой вариант обязательного запуска VS>> скрипта последним? EG> По-моему, такого и быть не может в такой формулировке: если ты EG> сделаешь два "последних" скрипта, который из них реально будет EG> последним? :-) Ты такие вопросы задаешь :-) Но современная система startup/shutdown скриптов могла бы предусматривать какие-то milestones, типа "эти скрипты запускать непосредственно перед выключением". Даже по-моему в SysV init была какая-то возможно это сделать, был уровень предусмотрен. EG> Я бы просто сделал скрипт с REQUIRE: SERVERS и назвал его EG> 000.something. Я тут подумал и решил, что поступлю тупо: в /usr/local/etc/apcupsd/apccontrol в процедуру doshutdown добавлю "service vm stop" перед ${SНUTDOWN}, и пусть сперва выключаются виртуалки сколько им надо, а потом уже вся система. Victor Sudakov, VAS4-RIPE, VAS47-RIPN --- GoldED+/BSD 1.1.5-b20160322-b20160322 |
#9
|
|||
|
|||
Re: Как правильно готовить apcupsd
Eugene Grosbein написал(а) к Victor Sudakov в Apr 19 14:14:26 по местному времени:
24 апр. 2019, среда, в 08:15 NOVT, Victor Sudakov написал(а): EG>> Я разве не упоминал в этом треде, что про штатное и дефолтное EG>> поведение apcupsd не стоит даже думать, потому как оно заточено под EG>> Linux? VS> А зачем же мейнтейнеры порта заточили его как под линукс? Это вопрос к маинтенеру, но думаю, что они ничего не затачивали, тупо не заморачивались. EG>>>> Я, правда, предпочитаю просто обозвать скрипт 000.something, EG>>>> чтобы он в обратном порядке гашения получился раньше. EG>>>> Можно ещё в стартовый скрипт бихайва добавить зависимость от EG>>>> 000.something, чтобы при загрузке у него порядок был позже, а EG>>>> при выключении раньше. Полно вариантов. VS>>> А штатный для rcNG является какой вариант обязательного запуска VS>>> скрипта последним? EG>> По-моему, такого и быть не может в такой формулировке: если ты EG>> сделаешь два "последних" скрипта, который из них реально будет EG>> последним? :-) VS> Ты такие вопросы задаешь :-) Но современная система startup/shutdown скриптов VS> могла бы предусматривать какие-то milestones, типа "эти скрипты запускать VS> непосредственно перед выключением". Даже по-моему в SysV init была какая-то VS> возможно это сделать, был уровень предусмотрен. Ну вот ниже, SERVERS для этого подходит: # REQUIRE: mountcritremote abi ldconfig savecore watchdogd # This is a dummy dependency, for early-start servers relying on # some basic configuration. EG>> Я бы просто сделал скрипт с REQUIRE: SERVERS и назвал его EG>> 000.something. В "прямом" порядке такой скрипт будет одним из первых при загрузке, считай сразу после ldconfig, а в обратном - одним из самых последних. Eugene -- Прекрасны тонко отшлифованная драгоценность; победитель, раненный в бою; слон во время течки; река, высыхающая зимой; луна на исходе; юная женщина, изнуренная наслаждением, и даятель, отдавший все нищим. (Дхарма) --- slrn/1.0.3 (FreeBSD) |
#10
|
|||
|
|||
Как правильно готовить apcupsd
Victor Sudakov написал(а) к eugen в Apr 19 20:19:26 по местному времени:
Dear eugen, 24 Apr 19 14:14, Eugene Grosbein wrote to me: EG>>> Я разве не упоминал в этом треде, что про штатное и дефолтное EG>>> поведение apcupsd не стоит даже думать, потому как оно заточено EG>>> под Linux? VS>> А зачем же мейнтейнеры порта заточили его как под линукс? EG> Это вопрос к маинтенеру, но думаю, что они ничего не затачивали, EG> тупо не заморачивались. Может я когда-нибудь напишу PR с предложениями, но сперва надо самому понять логику. EG>>>>> Я, правда, предпочитаю просто обозвать скрипт 000.something, EG>>>>> чтобы он в обратном порядке гашения получился раньше. EG>>>>> Можно ещё в стартовый скрипт бихайва добавить зависимость от EG>>>>> 000.something, чтобы при загрузке у него порядок был позже, а EG>>>>> при выключении раньше. Полно вариантов. VS>>>> А штатный для rcNG является какой вариант обязательного запуска VS>>>> скрипта последним? EG>>> По-моему, такого и быть не может в такой формулировке: если ты EG>>> сделаешь два "последних" скрипта, который из них реально будет EG>>> последним? :-) VS>> Ты такие вопросы задаешь :-) Но современная система VS>> startup/shutdown скриптов могла бы предусматривать какие-то VS>> milestones, типа "эти скрипты запускать непосредственно перед VS>> выключением". Даже по-моему в SysV init была какая-то возможно VS>> это сделать, был уровень предусмотрен. EG> Ну вот ниже, SERVERS для этого подходит: EG> # REQUIRE: mountcritremote abi ldconfig savecore watchdogd EG> # This is a dummy dependency, for early-start servers relying on EG> # some basic configuration. EG>>> Я бы просто сделал скрипт с REQUIRE: SERVERS и назвал его EG>>> 000.something. EG> В "прямом" порядке такой скрипт будет одним из первых при загрузке, EG> считай сразу после ldconfig, а в обратном - одним из самых последних. Наверное можно и так, но я при изучении /etc/rc.d нашел /etc/rc.shutdown.local. По-моему он ближе к задаче. А моя вот эта идея: VS> Я тут подумал и решил, что поступлю тупо: в VS> /usr/local/etc/apcupsd/apccontrol в процедуру doshutdown добавлю VS> "service vm stop" перед${SНUTDOWN}, и пусть сперва выключаются VS> виртуалки сколько им надо, а потом уже вся система. не работает, т.к. apcupsd сперва посылает упсу сигнал выключить питание, и потом уже запускает doshutdown. Но я не сдался и придумал новый вариант, и сегодня даже проверил его. В rc.conf.local пишем apcupsd_flags="--term-on-powerfail" А в /etc/rc.shutdown.local вставляем test -f /var/run/powerfail && /usr/local/sbin/apcupsd --killpower вроде в такой конфигурации работает так, как меня устраивает: apcupsd запускает процедуру doshutdown и прекращает работу. Система спокойно гаснет, в последний момент ещё раз запускается "apcupsd --killpower", примерно через 30 секунд после сообщения "system halted" питание выключается. Victor Sudakov, VAS4-RIPE, VAS47-RIPN --- GoldED+/BSD 1.1.5-b20160322-b20160322 |