Что это
Сервис Linux NUT (Network UPS Tools) — это комплекс программ мониторинга и управления различными блоками бесперебойного питания.
Что из себя представляют и как вообще работают Network UPS Tools.
Сервер, он же upsd. Как видно из названия - представляет из себя обычного демона (он же служба, он же сервис). Запускается он на том же компе, к которому физически (например по USB) подключён бесперебойник. В дебиане управляется скриптом /etc/init.d/nut-server. Настраивается конфигами: /etc/nut/upsd.conf, /etc/nut/upsd.users, /etc/nut/ups.conf. Но пути к конфигам NUT могут быть другими в другом дистрибутиве!
Драйверы. К ядру операционки они особого отношения не имеют, исполняются в юзерспейсе. Представляют из себя обычные исполнимые бинарники. Их много разных, лежат где-то приблизительно в /lib/nut, могут иметь какие-то свои специфические настройки (смотря для какого устройства и что это устройство умеет). Драйвер(ы) запускает upsd после того как почитает свои конфиги дабы получать через них информацию от ups-ов, после чего эти самые драйверы можно невозбранно увидеть в списке запущенных процессов. Конфиг читают из /etc/nut/ups.conf.
Клиент, он же монитор, он же upsmon. Несмотря на свою клиентскую сущность - обычно тоже работает как демон (управляется скриптом /etc/init.d/nut-client). А вот этот товарищ запущен может быть решительно где угодно - можно даже на NAS или свой телефон на ведроиде его воткнуть, хотя в последнем смысла не многим больше чем в троллейбусе из буханки белого (или чёрного) хлеба. Именно upsmon отвечает за то, чтобы тактически грамотно выключить компьютер, когда нет ни питания, ни надежды на его возобновление. Будучи клиентом - информацию о состоянии бесперебойника монитор получает, как нетрудно догадаться, от сервера, т.е. от upsd. Работать upsmon может в двух режимах: master - используется только на том же самом компьютере, к которому ups подключён управляющим проводом (например usb); либо в режиме slave - используется если компьютер питается от упса но не может им напрямую управлять. Отличие master от slave в общем-то только в том что master одновременно с завершением работы своей операционной системы отдаёт бесперебойнику команду отключить питание с нагрузки. Конфигурируется монитор через /etc/nut/upsmon.conf
Таймер, он же upssched. Эта программка входит в комплект, однако изначально NUT не настроен на то чтобы её использовать, это просто один из возможных вариантов, который upsmon запускает в качестве реакции на те или иные события, т.е. вместо upssched в настройках можно указать, к примеру, самописный скрипт. Однако делать этого имхо не стоит т.к. во-первых самописный скрипт всё равно можно (и придётся!) настроить на запуск из upssched-а, а во вторых - основная фишка upssched-а в том что он умеет работать с таймерами. Получив от upsmon-а ту или иную команду, upssched может запустить отсчёт времени, вместо того чтобы просто сразу же передать её некоему третьему исполнимому файлу. И лишь когда созданный таким образом таймер дотикает до нуля - команда будет передана к примеру в настроенный нами самописный скрипт (обзовём его, скажем, upssched-cmd, хотя это и не принципиально). Есть также возможность прервать работу ещё не дотикавшего таймера по команде от upsmon-а (например, в качестве реакции на событие "вернулось питание"). Созданные upssched-ом таймеры являются отдельными процессами и видны в их списке, причём в upssched предусмотрена защита от "гонки" процессов, которая с небольшой вероятностью может возникнуть если upsmon, реагируя на множество событий, начнёт очень часто вызывать upssched. Конфиг с настройками - /etc/nut/upssched.conf.
Стоит также сказать, что в debian-based-дистрибутивах скрипты инициализации читают файл /etc/nut.conf чтобы определить какие именно демоны вообще запускать. В других дистрибутивах вполне может быть что-то аналогичное - обратите внимание на документацию соответствующих пакетов и на то, что пишет пакетный менеджер при установке.
Схема работы
Да всё просто в общем то - скрипты инициализации запускают на одном и том же компьютере и upsd и upsmon, upsd запускает настроенный для имеющегося бесперебойника драйвер и начинает отслеживать его (бесперебойника) состояние. Upsmon подключается к upsd с указанными в настройках upsd именем и паролем пользователя, после чего тоже начинает внимательно наблюдать за состоянием бесперебойника. Как только бесперебойник оказывается в состоянии "питаюсь от батареи" - upsd узнаёт об этом от драйвера, а upsmon узнаёт уже от upsd. Upsmon смотрит свои настройки и видит - для состояния ONBATT он должен вызвать указанную в параметре NOTIFYCMD команду, передав ей через переменную окружения тип события - т.е., опять же, ONBATT. В NOTIFYCMD у нас указан upssched, который немедленно и запускается. Upssched смотрит уже свой собственный конфиг и видит, что получив событие типа ONBATT он должен запустить таймер (длительностью, к примеру, 60 секунд) с именем onbatt - ок, таймер запускается и начинает тикать. А теперь возможны варианты.
- Таймер может просто дотикать до нуля - тогда upssched берёт имя таймера, затем он берёт из своих настроек опцию CMDSCRIPT и запускает указанный в этой опции исполнимый файл (у нас будет upssched-cmd) с параметром, идентичным имени таймера. То есть он запустит upssched-cmd с параметром onbatt. Upssched-cmd в нашем случае будет самым обыкновенным bash-скриптом сcase-конструкцией, проверяющий переданный параметр и действующий в зависимости от этого самого параметра. Получив onbatt - скрипт во-первых ругнётся в логи (полезно для отладки), во-вторых отправит бесперебойнику команду shutdown.return (получив эту команду UPS подождёт ранее настроенное время и уберёт питание с нагрузки, а в случае восстановления питания - вернёт питание на нагрузку), в третьих - начнёт завершение работы операционной системы. Для отправки команды бесперебойнику мы воспользуемся командой upscmd - она входит в набор nut и тоже является клиентом для upsd т.е. подключается к нему по сети. Завершать работу операционки можно было бы, к примеру, просто командой halt, однако мы воспользуемся upsmon -c fsd - она во-первых заставляет upsmon передать сигнал fsd (forced shutdown) на upsd, что может быть важно если к upsd подключены upsmon с других, питающихся от того же UPS-а компьютеров, а во-вторых - выполняет собственно завершение работы операционки. По идее, работающий в режиме мастера upsmon при получении fsd должен ещё и обеспечивать передачу на UPS команды shutdown.return, однако "из коробки" оно в Debian на работает. Чтобы заработало - потребуется глубоко вникнуть в устройство скриптов, исполняющихся при завершении работы системы... короче гораздо проще отослать на UPS команду "руками", что и делает наш скрипт.
- Питание может вернуться до того как скрипт onbatt дотикает до нуля. Сигнал ONLINE при этом опять пойдёт по цепочке driver-upsd-upsmon-upssched. Последний, увидев в настройках что на ONLINE он должен остановить работу таймера onbatt - прибивает процесс таймера. Естественно таймер уже не дотикает и скрипт upssched-cmd вызван не будет.
- Чисто теоретически возможна ситуация, когда таймер ещё не дотикал, но от драйвера поступает сигнал LOWBATT - то есть бесперебойник уже на последнем издыхании. В этом случае upssched решает "резать, не дожидаясь перитонита", т.е. вызывает upssched-cmd с командой onbatt, не дожидаясь когда там дотикает таймер. В итоге компьютер попытается успеть выключиться до того как UPS окончательно сдохнет.
Теперь несколько слов о восстановлении питания. Что будет если питание вернётся когда upssched уже запустил обратный отсчёт времени, но завершение работы системы ещё не началось - понятно и уже расписано выше. Но обычно важно и чтобы сервер сам загрузился после того как электропитание будет восстановлено - для этого надо залезть в BIOS и найти там в разделе навроде "power management" опцию с названием что-то типа "AC Back Function". Называться и настраиваться оно может в общем то как угодно, особенно в BIOS-ах серверных материнок, главное смысл %). А смысл в том что системник включается сам сразу - как только появляется питание.
Если питание вернётся после того, как операционная система завершила работу, системник выключился, UPS тоже выключился (т.е. перестал подавать питание на нагрузку) - всё заработает и начнёт загружаться практически сразу. А вот если питание вернётся, к примеру, после того как операционка уже начала завершаться но системник ещё работает, либо после того как системник выключился но UPS ещё не отключался - тут возможны варианты. Совсем не факт что бесперебойник уберёт и потом вернёт питание по истечении настроенного для него времени если питание от сети уже вернулось - а в этом случае системник обратно не включится. Всё прямо зависит от того, как именно бесперебойник реагирует на восстановление питания после получения команды shutdown.return. В моём случае UPS действовал тактически грамотно во всех вариантах - т.е. после получения команды на отключение - он исправно ждал заказанные ему секунды, отключал питание с нагрузки, и только затем если питание от сети присутствовало - возвращал питание обратно. В идеале так и должно быть. Но вам стоит протестировать все возможные варианты, прежде чем оставлять сервер работать без присмотра. Иначе есть вероятность, что вас вытянут на работу утром в воскресенье потому что, например, сайт не работает. Если при тестировании выявились проблемы с загрузкой после восстановления питания, либо если просто очень важно чтобы сервер работал постоянно - возможно стоит настроить BIOS на включение, скажем, каждый день в 7 утра - если конечно в вашем биосе есть такая настройка.