1
1
Desc: Configuring automatic UPS shutdowns
4
4
Auth: Russell Kroll <rkroll@exploits.org>
9
If you are using any drivers that don't support ups.conf/upsdrvctl yet,
10
you will need to call them individually. This will be repeated later in
26
19
3. The upsmon master notices and sets "FSD" - the "forced shutdown"
27
20
flag to tell all slave systems that it will soon power down the load.
22
(If you have no slaves, skip to step 6)
29
24
4. upsmon slave systems see "FSD" and:
31
26
- generate a NOTIFY_SHUTDOWN event
32
- wait FINALDELAY seconds - typically 15
27
- wait FINALDELAY seconds - typically 5
33
28
- call their SHUTDOWNCMD
34
29
- disconnect from upsd when killed by init
36
5. The upsmon master system waits up to HOSTSYNC seconds for the slaves
37
to disconnect from upsd. If any are connected after this time,
38
upsmon stops waiting and proceeds with the shutdown process.
31
5. The upsmon master system waits up to HOSTSYNC seconds (typically 15)
32
for the slaves to disconnect from upsd. If any are connected after
33
this time, upsmon stops waiting and proceeds with the shutdown
40
36
6. The upsmon master:
42
- generates a NOTIFY_SHUTDOWN event.
43
- waits FINALDELAY seconds - typically 15.
38
- generates a NOTIFY_SHUTDOWN event
39
- waits FINALDELAY seconds - typically 5
44
40
- creates the POWERDOWNFLAG file - usually /etc/killpower
45
41
- calls the SHUTDOWNCMD
68
64
when to power off the UPS. You must check for this file, as you don't
69
65
want this to happen during normal shutdowns!
71
If you can use upsdrvctl to control your drivers, something like this
72
will probably work. Change the paths to suit your system:
67
You can use upsdrvctl to start the shutdown process in your UPS
68
hardware. Use this script as an example, but change the paths to
74
71
if (test -f /etc/killpower)
77
74
/usr/local/ups/bin/upsdrvctl shutdown
80
Make sure the filesystem containing upsdrvctl and your UPS
81
driver(s) is mounted when the system gets to this point.
83
*** Old driver notice: if your driver(s) can't be controlled through
84
upsdrvctl, you must shut them down individually, like this:
86
if (test -f /etc/killpower)
88
echo "Killing the power, bye!"
89
/usr/local/ups/bin/bestfort -k /dev/ttyS0
77
Make sure the filesystem containing upsdrvctl, ups.conf and your UPS
78
driver(s) is mounted when the system gets to this point. Otherwise
79
it won't be able to figure out what to do.
84
NOTE: If you run any sort of RAID equipment, make sure your arrays
85
are either halted (if possible) or switched to "read-only" mode.
86
Otherwise you may suffer a long resync once the system comes back up.
88
The kernel may not ever run its final shutdown procedure, so you
89
must take care of all array shutdowns in userspace before upsdrvctl
92
If you use software RAID (md) on Linux, get mdadm and try using
93
'mdadm --readonly' to put your arrays in a safe state. This has to
94
happen after your shutdown scripts have remounted the filesystems.
96
On hardware RAID or other kernels, you have to do some detective work.
97
It may be necessary to contact the vendor or the author of your
98
driver to find out how to put the array in a state where a power loss
99
won't leave it "dirty".
101
My understanding is that 3ware devices on Linux will be fine unless
102
there are pending writes. Make sure your filesystems are remounted
103
read-only and you should be covered.
92
105
Multiple UPS shutdowns
93
106
======================
162
175
interval. This way, they won't be stuck in the halted state with the UPS
163
176
running on line power.
181
The easiest way to see if your configuration will handle a power race
182
successfully is to do 'upsmon -c fsd'. This will force the UPS software
183
to shut down as if it had a OB+LB situation, and your shutdown script
184
should call the UPS driver(s) in shutdown mode.
186
If everything works correctly, the computer will be forcibly powered off,
187
may remain off for a few seconds to a few minutes (depending on the
188
driver and UPS type), then will power on again.
190
If your UPS just sits there and never resets the load, you are vulnerable
191
to the above power race and should add the "reboot after timeout" hack
165
194
Know your hardware
166
195
==================
169
198
model lines. You should test the shutdown sequence on your systems before
170
199
leaving them unattended. A successful sequence is one where the OS halts
171
200
before the battery runs out, and the system restarts when power returns.
205
If your UPS powers up immediately after a power failure instead of
206
waiting for the batteries to recharge, you can rig up a little hack to
207
handle it in software.
209
Essentially, you need to test for the POWERDOWNFLAG in your *startup*
210
scripts while the filesystems are still read-only. If it's there, you
211
know your last shutdown was caused by a power failure and the UPS
212
battery is probably still quite weak.
214
In this situation, your best bet is to sleep it off. Pausing in your
215
startup script to let the batteries recharge with the filesystems in a
216
safe state is recommended. This way, if the power goes out again, you
217
won't face a situation where there's not enough battery capacity left
218
for upsmon to do its thing.
220
Exactly how long to wait is a function of your UPS hardware, and will
221
require careful testing.
223
If this is too evil for you, buy another kind of UPS that will either
224
wait for a minimum amount of charge, a minimum amount of time, or both.
added
removed
docs/shutdown.txt
