This apparently implies that, unlike some docs say, the snmp-ups driver can send the shutdown signals (is not crippled by design)? ;) Also, are those oids apc-private or commonly used/standard among snmp upses? Thanks, //Jim Typos courtesy of my Samsung Mobile -------- ???????? ????????? -------- ??: Charles Lepple <clepple at gmail.com> ????: 2014.02.25 13:08 (GMT+01:00) ????: nut-upsdev at lists.alioth.debian.org ????: Re: [Nut-upsdev] snmp-ups shutdowns On Feb 19, 2014, at 11:18 AM, Tim Rice wrote:> On Wed, 19 Feb 2014, Jim Klimov wrote: > >> On 2014-02-19 03:04, Tim Rice wrote: >>> Now here are the OIDs (pick one) to actually turn the UPS off >>> after the shutdown delay. >>> >>> # reboot gracefully (APC) (stays off until utility power is restored) >>> UPS_OID=".1.3.6.1.4.1.318.1.1.1.6.2.2.0 integer 3"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 .1.3.6.1.4.1.318.1.1.1.6.1.1.0 (upsBasicControlConserveBattery), which is currently mapped to "shutdown.return">>> # turn off UP gracefully (APC) (stays off even if power is restored) >>> #UPS_OID=".1.3.6.1.4.1.318.1.1.1.6.2.1.0 integer 3"This should map to the "shutdown.stayoff" instant command. -- Charles Lepple clepple at gmail _______________________________________________ Nut-upsdev mailing list Nut-upsdev at lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20140227/a904b8d7/attachment.html>
On Feb 27, 2014, at 7:07 AM, jimklimov at cos.ru wrote:> 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: http://buildbot.networkupstools.org/~buildbot/cayman/docs/latest/docs/man/snmp-ups.html#_shutdown 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 :-) I should point out that with GitHub, it is a little easier to propose documentation edits: just fork the NUT repository, and in your fork, click the "Edit" button, and create a pull request. Theoretically, you could do this all from your phone :-) The big advantage there is not having to download the entire repository for a small fix. The intent with the AsciiDoc conversion of the man pages was to make it easier to edit documentation without being a *roff expert. https://github.com/networkupstools/nut/blob/master/docs/man/snmp-ups.txt> Also, are those oids apc-private or commonly used/standard among snmp upses?1.3.6.1.4.1.318 is the APC prefix - I don't think many UPSes use other vendors' prefixes. -- Charles Lepple clepple at gmail -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20140227/d0cb0a87/attachment.html>
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> > wrote: > >> 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: > > http://buildbot.networkupstools.org/~buildbot/cayman/docs/latest/docs/man/snmp-ups.html#_shutdown > > 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 >> upses? > > 1.3.6.1.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 .1.3.6.1.4.1.318.1.1.1.6.1.1.0 (upsBasicControlConserveBattery), which is currently mapped to "shutdown.return" > >>>> # turn off UP gracefully (APC) (stays off even if power is restored) >>>> #UPS_OID=".1.3.6.1.4.1.318.1.1.1.6.2.1.0 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? Thanks, //Jim Klimov