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

On Wed, 14 Oct 2015, Davide Baldini wrote:
>> Is there any command in the list provided by "upscmd -l
myups" which is
>> accepted by this UPS?
>
> None of the command sin the list successfully completes, not even 
> beeper.toggle.
It looks as if the problem is more general than turning off the UPS. The 
command mechanism is broken.
> I added -q and -D to /etc/nut/ups.conf, as:
>
>  [myups]
>    driver = nutdrv_qx -D -q
>    port = auto
>
> I couldn't find more info on where to append driver parameters, not
sure if
> that's the correct way. After that, I restarted nut with:
>
>  # service nut-server restart
>  # service nut-client restart
My naive reading of function conf_args in common/upsconf.c is that only 
the form driver = something is seen, any additional parameters are 
ignored.

I'm not sure how to add a debugging option to a "service" call in 
Debian.  Is /etc/init.d/nut-client a Bash/Dash script?  Is it possible to 
add the option to the call of the driver in this script?

Roger

On 10/14/2015 06:11 PM, Roger Price wrote:
> Is /etc/init.d/nut-client a Bash/Dash script?  Is it possible to add the
option to
> the call of the driver in this script?
Looks like some options can be passed: /etc/init.d/nut-client is a dash script 
and when it is started or restarted, it executes:

   start-stop-daemon -S -q -p $upsmon_pid -x $upsmon \
     -- $UPSMON_OPTIONS >/dev/null 2>&1 && return 0 || return
1

or simply, it runs

   $upsmon -- $UPSMON_OPTIONS

as a daemon, with these vars defined in the head of the script:

   $upsmon = "/sbin/upsmon"
   $UPSMON_OPTIONS = ""

$UPSMON_OPTIONS is set empty in the head of the script, and never ever assigned 
to. So I alter the script to set it:

   UPSMON_OPTIONS="-q -D"

then restart nut-server and nut-client. While restarting, they don't
complain
about these new parameters, and just log

   Communications with UPS myups at localhost established

into /var/log/syslog.

Then, nothing is different; issuing commands yields to the same exact results as
before, and syslog contains no additional details at all.
I guess that was not the right place where to append these debug parameters I 
also suspect the nut driver (nutdrv_qx) might not be the correct one for my ups.

-- Davide

Davide, given that your device has a VID:PID pair of 0xffff:0x0000 I
assume you're using the 'krauler' USB subdriver.
If that's the case (and it should be, at least going by the upsc
output you posted some time ago), then be aware that the driver
-currently- doesn't support shutdown commands:
http://www.networkupstools.org/docs/man/nutdrv_qx.html#_implementation_notes
Starting from 2.7.3 (some bugs have been fixed after that release and,
hence, I'd recommend current git HEAD) nutdrv_qx has a new USB
subdriver ('fabula') that's somewhat similar to the
'krauler' one and
that supports shutdown commands (but it still ignores
ups.delay.start/ondelay and makes the UPS turn on the load as soon as
power is back, as per my previous link): it may (or maybe not) work
with your device.
Once installed the new version, you should be able to test the new
subdriver specifying in ups.conf something like this:
    [ups]
        driver = nutdrv_qx
        port = auto
        subdriver = fabula
        vendorid = ffff
        productid = 0000
If you still don't have luck with the new subdriver, then -provided
that you have enough time (and patience to put up with me)- we can try
to see if we can add support for shutdown commands to the 'krauler'
subdriver.

On Oct 14, 2015, at 2:25 PM, Davide Baldini <baldiniebaldini at gmail.com>
wrote:
> 
> Then, nothing is different; issuing commands yields to the same exact
results as before, and syslog contains no additional details at all.
The portion you quoted was for upsmon - the debug output would come from the
driver instead.

The debug options enable logging to stderr, though - not to syslog. For future
reference, under Debian, you can start everything as usual, kill the existing
driver, then run the driver from the command line (optionally capturing stdout
and stderr to a file):

/lib/nut/nutdrv_qx -a myups -D 2>&1 | tee /tmp/log

For now, please try hyouko's recommendation. We have a number of posts in
the archives detailing how you can build the latest version of NUT for Debian -
let us know if you run into any issues.
> I guess that was not the right place where to append these debug parameters
I also suspect the nut driver (nutdrv_qx) might not be the correct one for my
ups.
The nutdrv_qx driver is the best match for your UPS; however, the vendor did not
even bother to get a legitimate USB ID (FFFF:0000) so it is not terribly
surprising that some commands do not work the same way as other models.

-- 
Charles Lepple
clepple at gmail