Nut upsuser - Aug 2020 - Synology NAS is shutting down Ubuntu servers after very brief power outage (fwd)

> grep nut /etc/passwd
nut:x:129:134::/var/lib/nut:/usr/sbin/nologin
> In your manual test do you restore utility power after 3-5 seconds?
Yes, I have tried that.  I have also tried less than one second.  I’ve tried for
1-2 minutes, for 3-5 minutes, I’ve tried just about every length of time and all
appears Ok when I manually test.

--
Todd Benivegna // todd at benivegna.com
On Aug 5, 2020, 3:26 AM -0400, Roger Price <roger at rogerprice.org>,
wrote:
> On Tue, 4 Aug 2020, Todd Benivegna wrote:
>
> > Sorry. I've lost the thread here, what is the "it" you
refer to?
> >
> > I’m not an linux expert so you’ll have to bear with me, but I guess
the it I
> > was referring to whatever NUT is using since what we’re editing is a
config
> > file, not a script; it doesn’t have a shebang at the top.
>
> The command sequence specified by the SHUTDOWNCMD declaration is called
from
> upsmon (a program written in C).
>
> > If you run the command
> > grep nut /etc/password
> >
> > I got:  grep: /etc/password: No such file or directory
>
> Sorry, my mistake it should be
>
> grep nut /etc/passwd
>
> > That may seem to be the case, however, whenever I test by manually
pulling the
> > power, the servers stay up and all appears normal.  It has happened
three
> > times now where I am away and the power goes out for 3-5 seconds and
the
> > servers shutdown and will stay down, even if I try to power back on,
until I
> > restart the Synology NAS.
>
> In your manual test do you restore utility power after 3-5 seconds?
>
> Roger
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20200805/62cf1651/attachment.html>

Ok guys,

So we just had a storm roll through and of course we lost power for just a split
second.  This time I was actually home for it.  Sure enough, the servers
shutdown and wouldn’t boot all the way up until I restarted my Synology.  I
grep’d the syslog and here’s the results:
> proton at proton:~$ sudo grep upsmon /var/log/syslog
> Aug  6 19:19:09 proton upsmon[1552]: UPS ups at 192.168.1.70 on battery
> Aug  6 19:19:14 proton upsmon[1552]: UPS ups at 192.168.1.70 on line power
> Aug  6 19:19:44 proton upsmon[1552]: UPS ups at 192.168.1.70: forced
shutdown in progress
> Aug  6 19:19:44 proton upsmon[1552]: Executing automatic power-fail
shutdown
> Aug  6 19:19:45 proton upsmon[1552]: Auto logout and shutdown proceeding
> Aug  6 19:19:50 proton upsmon.conf: UPS status is
> Aug  6 19:19:59 proton upsmon[1545]: fopen /run/nut/upsmon.pid: No such
file or directory
> Aug  6 19:19:59 proton upsmon[1545]: UPS: ups at 192.168.1.70 (slave)
(power value 1)
> Aug  6 19:19:59 proton upsmon[1545]: Using power down flag file
/etc/killpower
> Aug  6 19:19:59 proton systemd[1]: nut-monitor.service: Can't open PID
file /run/nut/upsmon.pid (yet?) after start: Operation not permitted
> Aug  6 19:19:59 proton upsmon[1557]: Startup successful
> Aug  6 19:19:59 proton upsmon[1558]: UPS [ups at 192.168.1.70]: connect
failed: Connection failure: Network is unreachable
> Aug  6 19:19:59 proton upsmon[1558]: Communications with UPS ups at
192.168.1.70 lost
> Aug  6 19:20:04 proton upsmon[1558]: UPS [ups at 192.168.1.70]: connect
failed: Connection failure: Network is unreachable
> Aug  6 19:20:04 proton upsmon[1558]: UPS ups at 192.168.1.70 is unavailable
> Aug  6 19:28:03 proton upsmon[1558]: Communications with UPS ups at
192.168.1.70 established
> proton at proton:~$ sudo upsc UPS at 192.168.1.70
> Init SSL without certificate database
> battery.charge: 100
> battery.charge.low: 10
> battery.charge.warning: 50
> battery.date: 2001/09/25
> battery.mfr.date: 2016/12/11
> battery.runtime: 2076
> battery.runtime.low: 120
> battery.type: PbAc
> battery.voltage: 13.6
> battery.voltage.nominal: 12.0
> device.mfr: American Power Conversion
> device.model: Back-UPS NS 650M1
> device.serial: 4B1650P02109
> device.type: ups
> driver.name: usbhid-ups
> driver.parameter.pollfreq: 30
> driver.parameter.pollinterval: 5
> driver.parameter.port: auto
> driver.version: DSM6-2-25364-191230
> driver.version.data: APC HID 0.95
> driver.version.internal: 0.38
> input.sensitivity: medium
> input.transfer.high: 139
> input.transfer.low: 92
> input.transfer.reason: input voltage out of range
> input.voltage: 121.0
> input.voltage.nominal: 120
> ups.beeper.status: enabled
> ups.delay.shutdown: 20
> ups.firmware: 929.a5 .D USB FW
> ups.load: 15
> ups.mfr: American Power Conversion
> ups.mfr.date: 2016/12/11
> ups.model: Back-UPS NS 650M1
> ups.productid: 0002
> ups.realpower.nominal: 360
> ups.serial: 4B1650P02109
> ups.status: OL
> ups.test.result: No test initiated
> ups.timer.reboot: 0
> ups.timer.shutdown: -1
> ups.vendorid: 051d
Looks like what we did earlier didn’t work as it just says “UPS Status is” with
nothing after it.  Also after grep’d the syslog I got the current status of the
UPS.

What do you think?  I really just don’t understand what the heck is going
on.  Like I said before, whenever I test manually it works!  This is crazy.

Thanks for all your help,

Todd

--
Todd Benivegna // todd at benivegna.com
On Aug 5, 2020, 7:29 AM -0400, Todd Benivegna <todd at benivegna.com>,
wrote:
> > grep nut /etc/passwd
>
> nut:x:129:134::/var/lib/nut:/usr/sbin/nologin
>
> > In your manual test do you restore utility power after 3-5 seconds?
> Yes, I have tried that.  I have also tried less than one second.  I’ve
tried for 1-2 minutes, for 3-5 minutes, I’ve tried just about every length of
time and all appears Ok when I manually test.
>
> --
> Todd Benivegna // todd at benivegna.com
> On Aug 5, 2020, 3:26 AM -0400, Roger Price <roger at rogerprice.org>,
wrote:
> > On Tue, 4 Aug 2020, Todd Benivegna wrote:
> >
> > > Sorry. I've lost the thread here, what is the "it"
you refer to?
> > >
> > > I’m not an linux expert so you’ll have to bear with me, but I
guess the it I
> > > was referring to whatever NUT is using since what we’re editing
is a config
> > > file, not a script; it doesn’t have a shebang at the top.
> >
> > The command sequence specified by the SHUTDOWNCMD declaration is
called from
> > upsmon (a program written in C).
> >
> > > If you run the command
> > > grep nut /etc/password
> > >
> > > I got:  grep: /etc/password: No such file or directory
> >
> > Sorry, my mistake it should be
> >
> > grep nut /etc/passwd
> >
> > > That may seem to be the case, however, whenever I test by
manually pulling the
> > > power, the servers stay up and all appears normal.  It has
happened three
> > > times now where I am away and the power goes out for 3-5 seconds
and the
> > > servers shutdown and will stay down, even if I try to power back
on, until I
> > > restart the Synology NAS.
> >
> > In your manual test do you restore utility power after 3-5 seconds?
> >
> > Roger
> > _______________________________________________
> > Nut-upsuser mailing list
> > Nut-upsuser at alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20200806/1025ae10/attachment-0001.html>

On Thu, 6 Aug 2020, Todd Benivegna wrote:
> ... I grep’d the syslog and here’s the results:
Could you also grep for upsd and upsmon in the NAS log?  Is this possible?
>       proton at proton:~$ sudo grep upsmon /var/log/syslog
>       Aug  6 19:19:09 proton upsmon[1552]: UPS ups at 192.168.1.70 on
battery
>       Aug  6 19:19:14 proton upsmon[1552]: UPS ups at 192.168.1.70 on line
power
>       Aug  6 19:19:44 proton upsmon[1552]: UPS ups at 192.168.1.70: forced
shutdown in progress
>       Aug  6 19:19:44 proton upsmon[1552]: Executing automatic power-fail
shutdown
So proton is a slave, and is being made to shut down.
>       Aug  6 19:19:45 proton upsmon[1552]: Auto logout and shutdown
proceeding
>       Aug  6 19:19:50 proton upsmon.conf: UPS status is 
The variable USPstatus set by getUPSstatus was not in the environment for the 
echo command.  To get this to work, you'll have to put the upsc commands 
directly in SHUTDOWNCMD, or create a short script and call the script in 
SHUTDOWNCMD.
>       Aug  6 19:19:59 proton upsmon[1545]: UPS: ups at 192.168.1.70 (slave)
(power value 1)
Could you tell us your topology?  Which system is master and which is slave? 
Do you have multiple slaves?  The decision to shutdown is taken by the master, 
not the slave.

Is it possible to run script http://rogerprice.org/NUT/nut-report on the NAS? 
Could you run the script on one of the slaves and post the result here?

Roger