Nut upsuser - Aug 2020 - UPS Reboots when Pi Reboots!

Thank you Roger, I appreciate the response. I'll have to check my commands,
I believe I started it with those systemctl commands you provided. What I can
say is that oddly enough after completing the server config and after two more
reboots a reboot of the Pi doesn't seem to be causing the UPS to reboot
anymore. I have a bit more config to do on slave machines tomorrow but after
that I'll do testing - including pulling the plug - and see what happens.

I do recall from reading the documentation that the master can initiate a reboot
of the UPS and that in a shutdown event I believe it's supposed to do
actually trigger a delayed shutdown to occur after the master's own
power-off. How that gets mixed up with an OS reboot is odd to me...perhaps
something scripted in relation to the NUT service stopping?

Google searching did by the way yield one and only one other mention of
something like what I experienced:
https://serverfault.com/questions/858267/network-ups-tools-nut-causing-ups-to-reboot.
So at least I'm not completely nuts, just partially.

Thanks again for your help.
-James

On Aug 15, 2020 10:44 PM, Roger Price <roger at rogerprice.org> wrote:
On Sat, 15 Aug 2020, James Fischl wrote:
> OS: Raspbian Lite 4.19 (Linux 5.4.51-v7l+ armv7l)NUT version: 2.7.4
> Install Method: Package (apt-get)
> Device Name: CyberPower CP1500PFCLCD, connected via USB
> Problem: This is a brand-new installation; the only step I've taken is
my initial edit of /etc/nut/ups.conf (which I'll post below). I started the
driver
> and after doing so issued a reboot command to my Raspberry Pi (sudo
reboot). After doing so my UPS rebooted itself, quite a problem given all the
other
> equipment connected to it. How do I prevent that from happening?
The usual way of starting NUT is

  systemctl start nut-server.service
  systemctl start nut-monitor.service

The driver will be started automatically by upsd (nut-server).  What happens if
you start that way?

what happens when you pull the wall power?

Roger

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20200816/3ab2977c/attachment.html>

On Sun, 16 Aug 2020, James Fischl wrote:
> Thank you Roger, I appreciate the response. I'll have to check my
commands, I
> believe I started it with those systemctl commands you provided. What I can
> say is that oddly enough after completing the server config and after two
more
> reboots a reboot of the Pi doesn't seem to be causing the UPS to reboot
> anymore. I have a bit more config to do on slave machines tomorrow but
after
> that I'll do testing - including pulling the plug - and see what
happens. 
One problem that NUT users have is that they correctly install and configure 
NUT, but then enter a command such as "shutdown -h now" to test the
setup.  The
effect is for the box to shutdown and then restart shortly afterwards, despite 
the "-h".  The true test is to pull wall power.
> I do recall from reading the documentation that the master can initiate a 
> reboot of the UPS and that in a shutdown event I believe it's supposed
to do
> actually trigger a delayed shutdown to occur after the master's own
power-off.
> How that gets mixed up with an OS reboot is odd to me...perhaps something 
> scripted in relation to the NUT service stopping? 
It is important to be clear as what is shutting down.  A possible sequence is:

  1. Wall power fails.  The UPS beeps.
  2. Master calls for server shutdown
  3. Server shuts down, leaving the UPS beeping.
  4. After a ups.conf specified delay the UPS turns off its power outlets and
     stops beeping. This is refered to as "delayed UPS shutdown".
  5. Later, wall power returns and is detected by the UPS.
  6. The UPS turns on its power outlets.
  7. The server reboots.

Roger