[Nut-upsdev] snmp-ups shutdowns
jimklimov at cos.ru
Thu Feb 27 14:43:25 UTC 2014
On 2014-02-27 14:21, Charles Lepple wrote:
> On Feb 27, 2014, at 7:07 AM, jimklimov at cos.ru <mailto:jimklimov at cos.ru>
>> This apparently implies that, unlike some docs say, the snmp-ups
>> driver can send the shutdown signals (is not crippled by design)? ;)
> We're working on it:
> A quick check says that the implementation has been there since v2.6.4,
> and the documentation caught up after v2.7.1. Without a SNMP UPS to test
> against in-house, you can imagine that I am not inclined to arbitrarily
> change things there without user feedback :-)
Ok, I'll have them give it a try :)
Also, is there any command to cancel a pending shutdown, if any was
requested previously - so as to reset the doomsday timer (so that, per
my earlier example, if several blades are shutting down and asking the
UPS to kill itself in a few minutes, every next blade that completes
its shutdown to this step, would give a few more minutes of uptime
to those which are still processing their stop-scripts)?
>> Also, are those oids apc-private or commonly used/standard among snmp
> 126.96.36.199.4.1.318 is the APC prefix - I don't think many UPSes use other
> vendors' prefixes.
hmmm.... right, thanks :)
> This OID is curiously commented out in drivers/apc-mib.c, and has been since the beginning of our revision control history. I don't see why we couldn't add it back in as an instant command.
> I wonder if there was some confusion with .188.8.131.52.4.1.3184.108.40.206.220.127.116.11 (upsBasicControlConserveBattery), which is currently mapped to "shutdown.return"
>>>> # turn off UP gracefully (APC) (stays off even if power is restored)
>>>> #UPS_OID=".18.104.22.168.4.1.322.214.171.124.126.96.36.199 integer 3"
> This should map to the "shutdown.stayoff" instant command.
And this means that the current code in the repository would not work
as expected, without fixing the above discrepancies first? Right?
More information about the Nut-upsdev