[Nut-upsuser] Unitek iZi UPS 525

[Arjen de Korte]

Ciprian Vizitiu wrote:

> Ok, most likely it's me but I'm out of ideas right now; last night my very
> first attempt was to use "NOTIFYCMD" with 
> 
> NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC
> NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC
> NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC
> 
> ... and the very simple script for sending mails worked just fine. So upsmon
> is actually taking into consideration "NOTIFYCMD" section. 

I presume that you see the status changes on upsmon reflected in the
system logs, do you? Upssched won't work for a UPS that you don't monitor.

> Next step was to try and add upssched to the very same script. No luck;
> reading the 4th time the doc, I've figured out that upssched must be the
> NOTIFYCMD param in order to work, apparently it can't be inside the script.
> So right now I have in upsmon.conf:
> 
> RUN_AS_USER nut
> 
> NOTIFYCMD /usr/sbin/upssched
> 
> NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC
> NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC
> NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC

OK, that should work. You did restart upsmon after making changes to the
upsmon.conf file, did you? Note that the daemons will not pickup any
changes in configuration files, unless you tell them to reread (or
restart) them.

> Before you ask:
> 
> -rwxr-xr-x 1 root root 21316 Jul 12 21:09 /usr/sbin/upssched*

Fine.

> Ok, upssched.conf:
> 
> CMDSCRIPT /usr/sbin/upssched-cmd
> 
> PIPEFN /var/run/upssched/upssched.pipe
> LOCKFN /var/run/upssched/upssched.lock
> 
> AT ONBATT Unitek at localhost START-TIMER onbattwarn 60
> AT ONLINE Unitek at localhost CANCEL-TIMER onbattwarn

If upssched is called, you should see this in the system logfile (and
you'll see that the PIPEFN exists). If not, it doesn't make sense to go
and modify the upssched-cmd file, since that will only be called after
the timer has elapsed.

> Ok, pipe folder first: 
> 
> drwxrwxrwx 2 nut nut 4096 Dec 26 00:46 /var/run/upssched

That is overly lenient, the following should be enough:

drwxr-xr-x 2 nut root 4096 2006-12-27 08:48 /var/run/upssched

Note that in some cases, being very lax will not work either. I know of
quite a few programs that will refuse to run when they determine that
the protections are not restrictive enough (although nut is not one of
them, so far). So you'd better get this right from the start.

> The script itself:
> 
> -rwxrwxrwx 1 nut nut 501 Dec 26 10:51 /usr/sbin/upssched-cmd*
> 
> ... I know, I know, I know; but I've ended up 777-ing everything just to see
> it working! :-@

Ditto.

> The script now looks like this:
> 
> #! /bin/bash
> #
> 
> #case $1 in
> #       onbattwarn)
> 
> #/usr/sbin/upsmon -c fsd
> 
> echo 'Booo' > /tmp/upstest
> 
> #               ;;
> #       *)
> #               logger -t upssched-cmd "Unrecognized command: $1"
> #               ;;
> #esac

NUT comes with an example script that logs to syslog. Please use that
first to checkout if everything works.

[...]

> BTW: It takes this Unitek UPS some 1 min to decide that the power is back.
> Scary so to say, at first it looks as if the system will never come back
> on-line after a power down. The displayed values for this timing are way
> smaller:
> 
> # upsrw Unitek at localhost
> [...]
> 
> [ups.delay.start]
> Interval to wait before (re)starting the load (seconds)
> Type: STRING
> Value: 3
> 
> Isn't that "3" supposed to mean "3 seconds"? Apparently not...

Restarting the load is something different than reporting the line
status. Also remember that you may be looking at the ups.delay.reboot
interval. Which one is used, depends on whether line voltage is present
or not at the time of sending the shutdown command to the UPS. Also note
that (although NUT will use a precision in seconds) the UPS may have a
reboot interval that can only be specified with a 1-minute interval. The
driver will probably round this up to one minute.

Best regards, Arjen