Re: [Nut-upsuser] CentOS 7, systemd, nut-monitor, and failing to shut down the UPS

[Charles Lepple]

On Feb 2, 2018, at 8:07 AM, Roger Price wrote:
> 
>>  # check to see if we need to actually shutdown the UPS then do it
>>  /usr/sbin/upsmon -K >/dev/null 2>&1 && /usr/sbin/upsdrvctl shutdown
> 
> I don't have NUT + systemd + CentOS/RHEL, but I'm confused by your script. 
> "upsdrvctl" is a front end to your driver.  You are sending a command via 
> upsdrvctl and via your driver _after_ you have stopped the driver?  And it 
> works?

Roger,

"upsdrvctl shutdown" does not talk to the running driver - it starts a new copy 
with the "-k" flag to kill power.

https://github.com/networkupstools/nut/blob/v2.7.4/drivers/upsdrvctl.c#L337
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] CentOS 7, systemd, nut-monitor, and failing to shut down the UPS

[Roger Price]

On Thu, 1 Feb 2018, Lee Damon wrote:


I've "fixed" this problem by modifying the nutshutdown script:
#!/bin/sh
# stop nut driver to free up access to the device
/sbin/systemctl stop nut-driver
# make sure it has time to die
sleep 2
# check to see if we need to actually shutdown the UPS then do it
/usr/sbin/upsmon -K >/dev/null 2>&1 && /usr/sbin/upsdrvctl shutdown


I don't have NUT + systemd + CentOS/RHEL, but I'm confused by your script. 
"upsdrvctl" is a front end to your driver.  You are sending a command via 
upsdrvctl and via your driver _after_ you have stopped the driver?  And it 
works?



How did/do you solve this problem?


I don't use the nutshutdown script, but rather a systemd service unit which is 
called much earlier in the shutdown process.  This allows logging of the action.
It's described in Appendix B.2 at 
http://rogerprice.org/NUT/ConfigExamples.A5.pdf#subsection.B.2


Roger

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] testing shutdown: pc not restarting; and "ups unavailable" messages

[nut . user . u830]

> NUT takes charge of sending the required commands through the driver; the 
> default values are load.off.delay 20 and load.on.delay 30.  These values can 
> be 
> changed by adding lines such as
> 
> offdelay = 30
> ondelay = 100
> 
> to the corresponding UPS section in file ups.conf.

This sounded like a very appealing and sensible suggestion, thanks, so I just 
tried it.

I edited /etc/nut/ups.conf to contain the following stanza

[cyber]
driver = usbhid-ups
port = auto
desc = "Cyber Power Systems VALUE800EILCD"
offdelay = 30
ondelay = 100

and then I "tested the shutdown sequence" with

sudo upsmon -c fsd

The computer duly shut down but then didn't come back up for 3 minutes, at 
which point I power-cycled it by removing and re-inserting the cable. (By the 
way, 5 seconds of off time wasn't enough to wake it up, but 30 was.)

So what else could be wrong? 

- Should I have written load.off.delay instead of offdelay?

- Should I have issued any other command to cause the driver to read its 
ups.conf file?

- Could it be that the second issue I reported in my original message to the 
list is also affecting what happens?
http://lists.alioth.debian.org/pipermail/nut-upsuser/2018-February/011034.html 


I am still getting quite a few console broadcasts that "UPS cyber@localhost is 
unavailable" and (a) I don't know why (b) I wonder if this is preventing nut 
from telling the UPS those new values for the on-delay and off-delay.

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Default value for ondelay

[Roger Price]

On Fri, 2 Feb 2018, nut.user.u...@neverbox.com wrote:


  I have an older box set up this way for continuous integration, and it needs 
to see more than a few seconds of power loss for the "always turn
  on" BIOS setting to work. I forget how many different intervals I tried, 
but 30 seconds of off time is reliable for that particular box.

Thanks. This matches my limited experience from yesterday with 2 computers 
including the one that's actually attached to the UPS I'm trying to get to
work. 

If power is cut and restored when the computer is already off (and with the 
always-on BIOS setting), then: short off time, it doesn't notice and it
remains off; long off time, it does come back on. I did one minute for "long" 
but didn't do binary partitioning of the interval to assess the exact
threshold.


The default values in ups.conf are currently offdelay = 20 and ondelay = 30.
In view of your findings, shouldn't the default ondelay be offdelay+30 or even
higher?

Roger
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] testing shutdown: pc not restarting; and "ups unavailable" messages

[nut . user . u830]

> I have an older box set up this way for continuous integration, and it needs 
> to see more than a few seconds of power loss for the "always turn on" BIOS 
> setting to work. I forget how many different intervals I tried, but 30 
> seconds of off time is reliable for that particular box.

Thanks. This matches my limited experience from yesterday with 2 computers 
including the one that's actually attached to the UPS I'm trying to get to 
work. 

If power is cut and restored when the computer is already off (and with the 
always-on BIOS setting), then: short off time, it doesn't notice and it remains 
off; long off time, it does come back on. I did one minute for "long" but 
didn't do binary partitioning of the interval to assess the exact threshold.___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser