[Nut-upsdev] [PATCH 19/36] My upcoming changes may vastly change ideas about additional monitoring.

[Arnaud Quette]

2012/3/9 Greg A. Woods <woods at planix.com>:
> From: "Greg A. Woods" <woods at planix.com>
>
> 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/