Nut upsuser - Mar 2015 - Problems with NUT 2.7.2 on CentOS 7 and using the Mini-Box OpenUPS

> 
> The documentation isn't explicit about this, but 'upsdrvctl
shutdown' is
> meant to be run after all of the other processes on the system have been
> killed, real filesystems have been unmounted, and the kernel shutdown
> syscall is about to be called. Usually the init scripts will take care of
this,
> although I don't know how CentOS handles that specifically.
> 
> If you want to test the low-battery shutdown procedure (where upsmon
> tells the rest of the system to shut down, then tells the UPS to power
off),
> you can run 'upsmon -c fsd' (Forced ShutDown). The init scripts
should call
> 'upsdrvctl shutdown' implicitly when everything else has stopped.
I wish it were explicit.  :)

You say to use FSD for testing the system...what do I use for real?   I thought
I was supposed to call upsdrvctl shutdown with some delay, and THEN begin
shutting down my PC, in the hopes I finish before the delay expires and the UPS
shuts off of the power supply.

When you say "the init scripts will take care of this", do you mean
that if I execute a system shutdown, it will automatically send the
"upsdrvctl shutdown" command at the end?

On Mar 13, 2015, at 10:14 AM, Rob Groner <rgroner at RTD.com> wrote:
>> 
>> The documentation isn't explicit about this, but 'upsdrvctl
shutdown' is
>> meant to be run after all of the other processes on the system have
been
>> killed, real filesystems have been unmounted, and the kernel shutdown
>> syscall is about to be called. Usually the init scripts will take care
of this,
>> although I don't know how CentOS handles that specifically.
>> 
>> If you want to test the low-battery shutdown procedure (where upsmon
>> tells the rest of the system to shut down, then tells the UPS to power
off),
>> you can run 'upsmon -c fsd' (Forced ShutDown). The init scripts
should call
>> 'upsdrvctl shutdown' implicitly when everything else has
stopped.
> 
> I wish it were explicit.  :)
Since that comment didn't come with any documentation patches attached,
I'm going to act like it never happened :)
> You say to use FSD for testing the system...what do I use for real?
Let's back up. I was recommending the use of 'upsmon -c fsd' for
simulating the low battery condition that upsmon reacts to. That allows testing
of the low battery shutdown process without actually draining the battery. It
sounds like you are describing a shutdown triggered by a sysadmin, rather than
upsmon.
> I thought I was supposed to call upsdrvctl shutdown with some delay, and
THEN begin shutting down my PC, in the hopes I finish before the delay expires
and the UPS shuts off of the power supply.
You could, although there is no delay parameter to 'upsdrvctl shutdown'
So you are at the mercy of whether the shutdown process finishes in
time.
> 
> When you say "the init scripts will take care of this", do you
mean that if I execute a system shutdown, it will automatically send the
"upsdrvctl shutdown" command at the end?
> 
IMHO, yes, this is the job of the distribution's packager: lining up the
scripts such that typing 'poweroff' will both shut down the UPS after a
delay, and shut down the computer (or halt it and wait for the UPS to cut power,
if the BIOS latches the power off state). If the distribution doesn't do
that, then I'd call it a misconfiguration or a bug (since at that point, the
packages are doing little more than helping the compilation stage). And with the
proliferation of init systems, configuration will probably be
distribution-specific from that point on.

See previous comments about not knowing what CentOS does. Debian (wheezy; not
sure about jessie yet) and Ubuntu have a "poweroff" action in
/etc/init.d/nut-client.

-- 
Charles Lepple
clepple at gmail

Charles,

Thanks again for your help, and sorry I didn?t :cc - noted for the future!

I?m suspicious that the OpenUPS doesn?t behave properly in a number of ways, of
which the USB traffic is the one of immediate concern. It seems to me that NUT
can read from it but probably not write to it: and the OpenUPS doesn?t flag ?low
battery? conditions correctly either. It does shut itself down at a battery
voltage I can configure (via MS windows) and it does provide a signal via a
cable to the power button that will trigger a linux shutdown - but it won?t do
this via USB. So it?s useable with that work-round but not as intended!

It also reports spurious values - you spotted the 3.9 million seconds! When on
input power, that?s what you get for runtime! A sensible value is passed when on
battery. Whether that matters is questionable. Various other values aren?t good
either, like battery current when running on battery. Again that?s not too
important as battery voltage, output voltage and output current are OK.

Mini-box support and documentation are very poor too - but you can?t help with
that!

I hope you can comment on the attached debug output which you requested. I?ve
provided two - one on battery and the other on input power (which is 15v for my
OpenUPS). (I have higher debug level options available but you asked for -DDD)

The command I used to start the driver was /usr/sbin/usbhid-ups -DDD -a openups

Finally, I?d be interested in the additional debug modes for usbhid-ups. This
isn?t a ?production system? currently; it?s my home automation server and it?s
getting rebuilt shortly as I?ve changed tack on a few things and it needs a
clean out anyway! So I will try anything!

Many thanks for your help.

Philip.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openups_drv_start_lineon.gz
Type: application/x-gzip
Size: 8755 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150314/f46ffa1e/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openups_drv_start_onbatt.gz
Type: application/x-gzip
Size: 8920 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150314/f46ffa1e/attachment-0003.bin>
-------------- next part --------------

> On 13 Mar 2015, at 23:17, Charles Lepple <clepple at gmail.com>
wrote:
> 
> On Mar 13, 2015, at 10:14 AM, Rob Groner <rgroner at RTD.com> wrote:
> 
>>> 
>>> The documentation isn't explicit about this, but 'upsdrvctl
shutdown' is
>>> meant to be run after all of the other processes on the system have
been
>>> killed, real filesystems have been unmounted, and the kernel
shutdown
>>> syscall is about to be called. Usually the init scripts will take
care of this,
>>> although I don't know how CentOS handles that specifically.
>>> 
>>> If you want to test the low-battery shutdown procedure (where
upsmon
>>> tells the rest of the system to shut down, then tells the UPS to
power off),
>>> you can run 'upsmon -c fsd' (Forced ShutDown). The init
scripts should call
>>> 'upsdrvctl shutdown' implicitly when everything else has
stopped.
>> 
>> I wish it were explicit.  :)
> 
> Since that comment didn't come with any documentation patches attached,
I'm going to act like it never happened :)
> 
>> You say to use FSD for testing the system...what do I use for real?
> 
> Let's back up. I was recommending the use of 'upsmon -c fsd'
for simulating the low battery condition that upsmon reacts to. That allows
testing of the low battery shutdown process without actually draining the
battery. It sounds like you are describing a shutdown triggered by a sysadmin,
rather than upsmon.
> 
>> I thought I was supposed to call upsdrvctl shutdown with some delay,
and THEN begin shutting down my PC, in the hopes I finish before the delay
expires and the UPS shuts off of the power supply.
> 
> You could, although there is no delay parameter to 'upsdrvctl
shutdown' So you are at the mercy of whether the shutdown process finishes
in time.
>> 
>> When you say "the init scripts will take care of this", do
you mean that if I execute a system shutdown, it will automatically send the
"upsdrvctl shutdown" command at the end?
>> 
> 
> IMHO, yes, this is the job of the distribution's packager: lining up
the scripts such that typing 'poweroff' will both shut down the UPS
after a delay, and shut down the computer (or halt it and wait for the UPS to
cut power, if the BIOS latches the power off state). If the distribution
doesn't do that, then I'd call it a misconfiguration or a bug (since at
that point, the packages are doing little more than helping the compilation
stage). And with the proliferation of init systems, configuration will probably
be distribution-specific from that point on.
> 
> See previous comments about not knowing what CentOS does. Debian (wheezy;
not sure about jessie yet) and Ubuntu have a "poweroff" action in
/etc/init.d/nut-client.
> 
> -- 
> Charles Lepple
> clepple at gmail
> 
> 
> 
> 
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser