2012/3/9 Greg A. Woods <[email protected]>: > From: "Greg A. Woods" <[email protected]> > > Remove the section on using external scripting to monitor other aspects > of devices and replace it with some suggestions about further > improvements that should be made to driver programs. > > Note that Python might be OK for implementing a completely stand-alone > separate monitoring program, however it would be wrong for any kind of > embedded scripting language. Lua or Scheme would be more appropriate. > --- > TODO | 34 ++++++++++++---------------------- > 1 file changed, 12 insertions(+), 22 deletions(-) > > diff --git a/TODO b/TODO > index 1c45636..4a4d7d8 100644 > --- a/TODO > +++ b/TODO > @@ -44,10 +44,10 @@ and drop this program on top of it. > - Parse ups.conf and open the state socket for a driver > - Send DUMPALL and enter a select loop > - Parse SETINFOs that change ups.status > -- When you get OB LB, shut down > +- When you get "OB LB", or "DYING", shut down > > -Completely unprivileged upsmon > -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > +Completely unprivileged "upsmon" > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > upsmon currently retains root in a forked process so it can call the > shutdown command. The only reason it needs root on most systems is that > @@ -81,28 +81,18 @@ All it has to do is dispatch the UPS name and event type. > > [start] [type] [length] <name> [stop] > > -Monitor program with interpreted language > -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > +Driver Improvement > +~~~~~~~~~~~~~~~~~~ > > -Once in awhile, I get requests for a way to shut down based on the UPS > -temperature, or ambient humidity, or at a certain battery charge level, > -or any number of things other than an "OB LB" status. It should be > -obvious that adding a way to monitor all of that in upsmon would bloat > -upsmon for all those people who really don't need anything like that. > +Continue extending drivers to report alarms properly, and to monitor for > +emergency situations requiring emergency power off. > > -A separate program that interprets a list of rules and uses it to > -monitor the UPS equipment is the way to solve this. If you have a > -condition that needs to be tested, add a rule. > +Make sure all drivers can, if at all possible, shut down a UPS that is > +still online with the "shutdown.stayoff" command to allow scripts to > +explicitly shut down a UPS that's still running on mains power for the > +case where "upsmon" is responding to a key device that has reported that > +it is in the emergency "DYING" state. > > -Some of the tools that such a language would need include simple > -greater-than/less-than testing (if battery.charge < 20), equivalence > -testing (if ups.model = "SMART-UPS 700"), and some way to set and clear > -timers. > - > -Due to the expected size and limited audience for such a program, it > -might have to be distributed separately. > - > -NOTE: Python may be a good candidate. > > Sandbox > ~~~~~~~
I'm postponing this one, since it requires more discussions (that have somehow already started, but which I've missed...) cheers, Arnaud -- Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.free.fr/ _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
