Yes, that one. It made me thinking there might be some sidetrick to do
an actual shutdown.return even if it is currently reported as not available.
Yes, I know all these technicalities. Fortunately, load.off.delay works
as expected in my case, with a granularity of a second, because of
course I live-tested it. Determinate or not, 15 seconds turned out to be
enough for all servers to shutdown themselves so by the time load is
turned off, nothing is working from it. That is not the problem.
No, the power won't return that quick. It usually takes 3 to 4 hours.
Local specifics, so no power races in this case. Not the problem also.
I am not newbie to the Linux world as I use Gentoo throughout, but I
wasn't able to quickly figure out how to setup upsmon(+upssched?) to
perform the tasks I need. The workflow I need seems to be marginal
compared to the typical scenarios. Custom solution also allows me to
integrate things like SMS notification in the process.
But once again, this is not the problem.
The problem is getting UPS to turn on the load as soon as power mains
returns. Servers will start automatically. If a way to do this with my
model is discovered, I will modify my daemon to use it instead of just
load.off.delay'ing.
So, where do I look/dig ? Or is this a dead end and I better buy other
UPS model with an actual support?
Best regards,
G.
01.01.2023 19:25, Jim Klimov пише:
I wonder if you refer to
https://nut-upsuser.alioth.debian.narkive.com/Fj636tRZ/support-of-shutdown-return-on-a-apc-back-ups-cs-500
discussion from a decade ago...
Essentially, with the command you tell the UPS to cut power in X
seconds from now (some may not support it at all, some may have
effective minimal units e.g. some CPS use whole 30 or 60 second chunks
- so asking to go down in 59 sec often means immediately in fact).
This is a risky thing to request while the OS just begins a shutdown
and would take indeterminate time to stop all services and unmount
filesystems.
Traditionally NUT "killpower" handling was injected into the end of
(init/rc-script driven) shutdown routine. While the drivers and upsd
were stopped as any other services, another copy of the driver is
spawned in the final seconds to tell the ups to cut power (on the
primary server in upsmon terms).
Often this part of code also deals with a "power race condition" (on
all clients) - as your systems take time to go down, wall power may
return and some UPS models may refuse to continue emergency power off.
Power consumers should wait "a lot" (more time than the UPS provides
normally) and reboot.
Nowadays systemd allows shutdown hooks for similar effect, other
frameworks (e.g. SMF) might not. Anyhow these tricks may be
time-limited by the framework ("we were asked to go down, so `killall
-9` after X sec").
Still, wondering what was "too convoluted" with standard upsmon? What
could be done better? Note recent ML discussions about `upssched` use
that may allow for finer-grained reaction (but that is tangentially
related and may be "convoluted" indeed).
Hope this helps,
Jim Klimov
On Sun, Jan 1, 2023, 10:41 Gennadiy Poryev via Nut-upsuser
<[email protected]> wrote:
Hi all and happy new year!
I have a server minifarm at home but it's Kyiv/Ukraine so wall power
goes on and off unexpectedly quite a few times a day. What I want
is for
servers to gracefully start when power appears and gracefully shut
down
when it disappears.
To that end I've got some APC Back-UPS RS 1000, set up an usbhid-ups
driver and upsd. upsmon configuration turned out to be too
convoluted so
I decided to write my own custom solution, since the protocol is
fairly
simple.
So the daemon I wrote connects to upsd and monitors input.voltage and
ups.status. BTW had to override pollinterval = 1 and pollfreq = 1 in
ups.conf to make input.voltage report input voltage in more or less
real-time instead of cached.
The code logic is such that as soon as input.voltage goes below
input.transfer.low and ups.status goes from OL to OB the farm
shutdown
is initiated and ups is issued INSTCMD load.off.delay command and is
smart enough to shut itself down too.
So far this part of the project works OK -- the farm turns itself off
nicely and unattended.
BUT.
There seem to be lack of facility to do shutdown.return though. Still
have to to that manually each time.
I've attached upsc/upscmd/upsrw outputs but so far haven't figured
out a
combination that might do the trick. Provided my UPS can do it, of
course, but why shouldn't it?
From what I've read in the certain discussion on this maillist that
occurred 12 years ago and from nut documentation I suspect the
hope is
not lost and it is possible to somehow hack in proper shutdown.return
But my expertise ends here. Should anyone help me run all the
debug mode
magic I've read of and make good use of it, my thankfullness will
have
no bounds.
Best regards,
G.
_______________________________________________
Nut-upsuser mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
_______________________________________________
Nut-upsuser mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
