Nut upsuser - Oct 2015 - No power cycle after shutdown on Atlantis Land OnePower A03-S1001

Hello,

my Atlantis UPS (model on "subject" line) fails to cycle off the
outlet power after a power failure
on the mains followed by an automatic shutdown of the computer. The UPS simply
remains always on,
preventing the computer from restarting.

** Setup: **

Nut version 2.7.2
Nut driver blazer_usb
Linux 4.1.1


The config files are pretty default; the peculiar customization is NOTIFYCMD
from
/etc/nut/upsmon.conf, which is:

     NOTIFYCMD /usr/local/bin/ups_events.sh

 From the bottom of the same upsmon.conf, the ONLINE and ONBATT events have the
additional "+EXEC"
flag, so these events are passed to my ups_events.sh .

This script is straightforward, pastebin here:
https://pastebin.mozilla.org/8848229
Apart from keeping logs, the only actions the script performs are:


   ? when ONBATT is received:
     shutdown -h +3 &
     upscmd -u admin -p mypass myups shutdown.return 360

   ? when ONLINE is received:
     shutdown -c
     upscmd -u admin -p mypass myups shutdown.stop

and everything seems to work fine, no errors reported, and even from
/var/log/syslog all seems smooth:

     Instant command: admin at 127.0.0.1 did shutdown.return with value
"360" on myups
     instcmd(shutdown.return, 360)
     instcmd: command [shutdown.return] handled

When I manually unplug the mains, the computer waits 3 minutes, shutdowns, and
there it stays. As
per the above commands, issued from ups_events.sh, it is instead supposed to
boot up after 6 minutes
(360 / 60 seconds) counted from t?, the moment of the unplug. After 20 seconds
from the shutdown,
and largely before the 6-minutes scheduled cycle, the UPS LEDs indicate the
battery is again fully
charged (*). Ever after the shutdown, the UPS appears to never cycle its output,
and the computer
doesn't restart.

(*) Side note: the UPS is moderately heavy duty, with redundant batteries, and
the computer drains
approx. 25% of its nominal output power; this is to justify the fast recharge.


-- Davide

On Oct 2, 2015, at 9:01 PM, Davide Baldini <baldiniebaldini at gmail.com>
wrote:
> 
> When I manually unplug the mains, the computer waits 3 minutes, shutdowns,
and there it stays. As per the above commands, issued from ups_events.sh, it is
instead supposed to boot up after 6 minutes (360 / 60 seconds) counted from t?,
the moment of the unplug. After 20 seconds from the shutdown, and largely before
the 6-minutes scheduled cycle, the UPS LEDs indicate the battery is again fully
charged (*). Ever after the shutdown, the UPS appears to never cycle its output,
and the computer doesn't restart.
I'm not sure how this changes things, but the blazer driver ignores any
parameters for instant commands (other than "test.battery.start"). It
gets the "offdelay" and "ondelay" parameters from the
command line or ups.conf.

You might consider the "nutdrv_qx" driver instead - it is somewhat
more consistent with units for the various timers. I believe you can change the
delays at runtime as well, but via upsrw instead of command parameters.

Can you explain your test procedure again, with more details as to when you
unplug the power, and when the driver attempts to send the shutdown command? You
may be running into this:
http://www.networkupstools.org/docs/FAQ.html#_i_8217_m_facing_a_power_race

-- 
Charles Lepple
clepple at gmail

I changed the driver from blazer_usb to nutdrv_qx, by editing /etc/nut/ups.conf.
To apply changes, I did:

# service nut-server restart
# service nut-client restart

Then I've run a second test, this time simpler than the first one described
in
my previous email; the test only consists in toggling off/on a wall switch which
controls power to the UPS. This way, electric ground remains attached. I've
run
a shorter test because I had already experimented with the nutdrv_qx driver some
days ago and I noticed error messages appearing as soon as the power was 
switched off.


** THE TEST **

The test begins with the computer powered on and the UPS battery fully charged.
The procedure:

TIME [s]	ACTION
0		computer is on, UPS fully charged. I switch off the power
15		I switch on the power
25		UPS LEDs indicate the battery has fully recharged


** THE LOGS **

After this, I return upstairs at my monitor and check the logs via SSH.
An excerpt taken from /var/log/syslog at the time I run the test shows:

Oct  6 19:03:07 debianBunker upsmon[3115]: UPS myups at localhost on battery
Oct  6 19:03:07 debianBunker upsd[2946]: Instant command: admin at 127.0.0.1 did
shutdown.return with value "360" on myups
Oct  6 19:03:07 debianBunker nutdrv_qx[2936]: instcmd(shutdown.return, 360)
Oct  6 19:03:07 debianBunker nutdrv_qx[2936]: instcmd: FAILED
Oct  6 19:03:22 debianBunker upsmon[3115]: UPS myups at localhost on line power
Oct  6 19:03:22 debianBunker upsd[2946]: Instant command: admin at 127.0.0.1 did
shutdown.stop on myups
Oct  6 19:03:22 debianBunker nutdrv_qx[2936]: instcmd(shutdown.stop, [NULL])
Oct  6 19:03:25 debianBunker nutdrv_qx[2936]: instcmd: FAILED


When some days ago I did run a full shutdown test with this nutdrv_qx driver, 
the practical result was the same as with blazer_usb: after 3 minutes of running
on UPS batteries, the computer shut down in a controlled manner, then it 
remained off because the UPS didn't obey to (or didn't receive) the 
"shutdown.return" command, which should force the UPS to briefly
interrupt power
to the computer, allowing it to restart.

-- Davide