Some people (myself included) have several Linux PCs connected to one UPS. One PC monitors the UPS and needs to get the other PCs to shut down when the power goes out. There are a number of ways to do this, all are do-it-yourself currently, and most are just hypothetical.
We assume the PCs can communicate over a network. Call the PC that monitors the UPS the master & the other PCs the slaves.
Set up a port on the master which, when connected to, either sends "OK", "FAIL", or "BATLOW", the first when the power is ok, the second when the power has failed, and the third when the battery is low. Model this on port 13 (the time port) which one can telnet to & receive the local time.
Have the slaves run versions of powerd that look at this port instead of checking a serial line.
I think this is probably the best method, and intend to eventually upgrade my systems to use it.
Same as section UPS status port method except send an ethernet broadcast message that the power has just gone down.
This might have security implications, since it could be spoofed.
Set up dummy logins on the slaves with login names powerok and
powerfail, both with the same UID. Make /etc/powerokscript the
shell of the powerok user, and make /etc/powerfailscript the shell of
the powerfail user. On the master, have the /etc/powerokscript rlogin
to each slave as user powerok and have the /etc/powerfailscript rlogin
to each slave as user powerfail. Put a .rhosts file on each slave in
the home directory of powerok and powerfail to allow root from the
master to login as user powerok and powerfail to each slave.
This is the system I'm currently using. Unfortunately, there are some
difficulties in getting the remote logins to execute and return
without hanging. One probably wants the /etc/powerfailscript
on the master to rsh to the slaves in background so that the
/etc/powerfailscript doesn't hang. However, I never managed
to get logging in in background to work right. I even tried arcane
combinations such as having /etc/powerfailscript run foo
in background and having foo log into the slave. Whatever I did
gave problems with the thing being stopped for tty input (or output, I
can't remember).
Also, this might create security holes.