From gdt at lexort.com  Tue Oct  4 00:03:47 2022
From: gdt at lexort.com (Greg Troxel)
Date: Mon, 03 Oct 2022 19:03:47 -0400
Subject: [Nut-upsuser] NUT can't connect to USB UPS on OpenBSD
In-Reply-To: <CAKyvPyZHch6O7iegwhW2_twZgOvD7ZyMftBTkkbzmanRAYPbWw@mail.gmail.com>
 (=?utf-8?Q?=22Marc-Andr=C3=A9?= Harbec"'s message of "Mon, 3 Oct 2022
 14:40:22 -0400")
References: <CAKyvPyYXEEarf_7xTM7A+LKXp6w1pcdf7h12wBiCbtC_Q2kDfw@mail.gmail.com>
 <29E62E1F-79EE-4228-BD98-AB7E2B60CFC5@gmail.com>
 <rmiczd6g5x4.fsf@s1.lexort.com>
 <CAKyvPyZHch6O7iegwhW2_twZgOvD7ZyMftBTkkbzmanRAYPbWw@mail.gmail.com>
Message-ID: <rmik05gfr1o.fsf@s1.lexort.com>


Glad you got it working.


Marc-Andr? Harbec <maharbec at gmail.com> writes:

> Also, I found I had to manually start the USB driver. In my case:
> `usbhid-ups`. I don't know if it's something that needs to be done on
> all platforms (or it's OpenBSD specific), but I haven't read anything
> on this in the official documentation. The `upsd` daemon won't start
> if the driver is not already running, and it won't spawn it itself. I
> had too create my own service file for it:
>
>     $ cat /etc/rc.d/usbhid_ups
>     #!/bin/ksh

In pkgsrc (and hence on NetBSD), there is a /etc/rc.d/upsdriver and that
seems to run something that looks in /usr/pkg/etc/nut/ups.conf.   I have
a Best unit and that starts it at boot.   So you could perhaps create a
generic driver rcfile and use 'upsdrvctl start'.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20221003/467026b8/attachment.sig>

From maharbec at gmail.com  Mon Oct  3 19:40:22 2022
From: maharbec at gmail.com (=?UTF-8?B?TWFyYy1BbmRyw6kgSGFyYmVj?=)
Date: Mon, 3 Oct 2022 14:40:22 -0400
Subject: [Nut-upsuser] NUT can't connect to USB UPS on OpenBSD
In-Reply-To: <rmiczd6g5x4.fsf@s1.lexort.com>
References: <CAKyvPyYXEEarf_7xTM7A+LKXp6w1pcdf7h12wBiCbtC_Q2kDfw@mail.gmail.com>
 <29E62E1F-79EE-4228-BD98-AB7E2B60CFC5@gmail.com>
 <rmiczd6g5x4.fsf@s1.lexort.com>
Message-ID: <CAKyvPyZHch6O7iegwhW2_twZgOvD7ZyMftBTkkbzmanRAYPbWw@mail.gmail.com>

I found the solution, thanks to both of you for suggesting `ktrace`!

I know it's been a couple of months, but it was just a side project
and I finally got time to get back to it. And I thought it would maybe
help others by putting my findings into the mailing archive.

With `ktrace`, I was able to deduce that there was something weird
going on with my permissions on the USB device `/dev/usb0` (the one
where everything resides in my OpenBSD setup).

    $ doas ls -l /dev/usb0
    crw-r----- 1 root usb 61, 0 Jun 24 16:21 /dev/usb0

Turns out, if I want to run NUT with a user found within the group
`usb` (user is `_ups`), I need to allow write access to the group on
the device.

Also, I found I had to manually start the USB driver. In my case:
`usbhid-ups`. I don't know if it's something that needs to be done on
all platforms (or it's OpenBSD specific), but I haven't read anything
on this in the official documentation. The `upsd` daemon won't start
if the driver is not already running, and it won't spawn it itself. I
had too create my own service file for it:

    $ cat /etc/rc.d/usbhid_ups
    #!/bin/ksh

    daemon="/usr/local/bin/usbhid-ups"
    daemon_user="_ups"
    daemon_flags="-a eaton1"

    . /etc/rc.d/rc.subr

    pexp="${daemon} ${daemon_flags}"
    rc_reload=NO

    rc_cmd $1

With all that (read/write on the device + usb driver), and with all
the same config as found in my original email, I can finally make NUT
work on OpenBSD via only `rcctl`:

    $ doas rcctl start usbhid_ups
    $ doas rcctl start upsd
    $ doas rcctl start upsmon


On Thu, Aug 11, 2022 at 11:23 AM Greg Troxel <gdt at lexort.com> wrote:
>
>
> Charles Lepple via Nut-upsuser <nut-upsuser at alioth-lists.debian.net>
> writes:
>
> > If that fails, I'd recommend using ktrace to find out what is failing,
> > such that you get the "no USB buses found" error.
>
> Definitely.  I would actually recommend ktrace first.  Then just
> `kdump | egrep NAMI` will probably find the issue fast.
>
> I use nut on NetBSD, and have done "manual kludge udev" by knowing what
> serial port my UPS is going to be on  and in rc.local chowning it to nut
> and linking it to /dev/tty.ups which is in the config.  That's serial,
> not USB, but the same thing should work.
>
> And agreed on /dev/ugen; I have a USB printer on /dev/ugen1.01
>
> I suspect that nut needs to read /dev/usbN (for the bus that the UPS is
> on) and read-write access to the ugen file for the HID endpoint, which
> might be ugen, or it might be /dev/uhid2 (assuming it's like NetBSD in
> this regard).


From jimklimov+nut at gmail.com  Tue Oct  4 10:08:19 2022
From: jimklimov+nut at gmail.com (Jim Klimov)
Date: Tue, 4 Oct 2022 11:08:19 +0200
Subject: [Nut-upsuser] NUT can't connect to USB UPS on OpenBSD
In-Reply-To: <rmik05gfr1o.fsf@s1.lexort.com>
References: <CAKyvPyYXEEarf_7xTM7A+LKXp6w1pcdf7h12wBiCbtC_Q2kDfw@mail.gmail.com>
 <29E62E1F-79EE-4228-BD98-AB7E2B60CFC5@gmail.com>
 <rmiczd6g5x4.fsf@s1.lexort.com>
 <CAKyvPyZHch6O7iegwhW2_twZgOvD7ZyMftBTkkbzmanRAYPbWw@mail.gmail.com>
 <rmik05gfr1o.fsf@s1.lexort.com>
Message-ID: <CAJYg8vJfVAw4OqF-8G-zfjemvZBHKihQQLmZrT9HF==ViTr+TA@mail.gmail.com>

As for startup - yes, it was always the case that drivers and upsd (data
server) start separately even if on the same machine. They may be owned by
different user accounts crossing paths just for the pipe interaction (by
being in the same group with RW access to driver's pipe file) and not
necessarily even start as root to drop privileges later, so generally one
can not and should not start the other.

Later versions of NUT introduced `upsdrvctl` to abstract management of
driver process lifecycle (so you do not fiddle in init-scripts with
`usbhid-ups`, `snmp-ups` and similar driver program names).

Also if you start upsd before the drivers, I think even in earlier releases
it should just run a loop waiting for pipe files to appear (they
connect/reconnect on the fly). Before NUT v2.8.0 an upsd would refuse to
start if there are no driver definitions however. Since 2.8.0 there is a
boolean config-file/envvar option ALLOW_NO_DEVICE=true to allow starting
the data server with an empty ups.conf, so you can reload config with a
signal later on as you populate it.

Also NUT v2.8.0 rearranged reference service unit layouts (for Linux
systemd and Solaris/illumos SMF - PRs welcome for others) to have each
driver wrapped as a separate instance that can have its own service
dependency tree (e.g. `snmp-ups` should start after networking while
USB/serial/i2c drivers do not care about it) and even run-time user (e.g.
root for USB/serial if no other way to grab the device node is easy). This
is managed by `nut-driver-enumerator` (can run once, or as a looping
daemon) and `upsdrvsvcctl`. However being NUT reference concepts, these
solutions may have propagated or not into actual OS distributions.

For the driver service, you may want to ensure that it restarts if aborted
(e.g. USB cable replugged or chip reset => device lost => driver exited).
In some situations things try to reconnect but do not always succeed, nor
try indefinitely, to do so.

Hope this helps,
Jim Klimov

On Tue, Oct 4, 2022 at 1:03 AM Greg Troxel <gdt at lexort.com> wrote:

>
> Glad you got it working.
>
>
> Marc-Andr? Harbec <maharbec at gmail.com> writes:
>
> > Also, I found I had to manually start the USB driver. In my case:
> > `usbhid-ups`. I don't know if it's something that needs to be done on
> > all platforms (or it's OpenBSD specific), but I haven't read anything
> > on this in the official documentation. The `upsd` daemon won't start
> > if the driver is not already running, and it won't spawn it itself. I
> > had too create my own service file for it:
> >
> >     $ cat /etc/rc.d/usbhid_ups
> >     #!/bin/ksh
>
> In pkgsrc (and hence on NetBSD), there is a /etc/rc.d/upsdriver and that
> seems to run something that looks in /usr/pkg/etc/nut/ups.conf.   I have
> a Best unit and that starts it at boot.   So you could perhaps create a
> generic driver rcfile and use 'upsdrvctl start'.
> _______________________________________________
> 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/20221004/f4701769/attachment.htm>

From ml at netfence.it  Tue Oct 11 13:29:46 2022
From: ml at netfence.it (Andrea Venturoli)
Date: Tue, 11 Oct 2022 14:29:46 +0200
Subject: [Nut-upsuser] APC SmartUPS powercycles when power returns
Message-ID: <11f57705-7dcc-986c-7083-543dc738bbbc@netfence.it>

Hello.

I've got an APC SmartUPS 1500: it's connected via USB and I'm using the 
usbhid-ups driver. This used to work properly until recently.

Now, when power goes out it keeps on going on battery potentially for 
several minutes, but, the moment line returns, I hear a click and power 
is cycled on the outlets (so every computer is rebooted forcily).

I'm thinking about a hardware issue, but could it be that NUT is 
instructing it to do so?

All I see in the logs before the nasty event is: "upsmon[89989]: UPS 
APC at localhost on battery".
So I don't think a low battery status was reached and/or a shutdown 
initiated.



# upsc APC
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.runtime: 3540
battery.runtime.low: 120
battery.type: PbAc
battery.voltage: 27.1
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Smart-UPS 1500
device.serial: AS1425215186
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 15
driver.parameter.pollinterval: 2
driver.parameter.pollonly: true
driver.parameter.port: auto
driver.parameter.synchronous: auto
driver.version: 2.8.0
driver.version.data: APC HID 0.98
driver.version.internal: 0.47
driver.version.usb: libusb-1.0.0 (API: 0x1000102)
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.firmware: UPS 08.8 / ID=18
ups.mfr: American Power Conversion
ups.mfr.date: 2014/06/20
ups.model: Smart-UPS 1500
ups.productid: 0003
ups.serial: AS1425215186
ups.status: OL
ups.timer.reboot: -1
ups.timer.shutdown: -1
ups.vendorid: 051d



  bye & Thanks
	av.


From gdt at lexort.com  Tue Oct 11 14:17:01 2022
From: gdt at lexort.com (Greg Troxel)
Date: Tue, 11 Oct 2022 09:17:01 -0400
Subject: [Nut-upsuser] APC SmartUPS powercycles when power returns
In-Reply-To: <11f57705-7dcc-986c-7083-543dc738bbbc@netfence.it> (Andrea
 Venturoli via Nut-upsuser's message of "Tue, 11 Oct 2022 14:29:46
 +0200")
References: <11f57705-7dcc-986c-7083-543dc738bbbc@netfence.it>
Message-ID: <rmifsfuo5yq.fsf@s1.lexort.com>


Andrea Venturoli via Nut-upsuser <nut-upsuser at alioth-lists.debian.net>
writes:

> I've got an APC SmartUPS 1500: it's connected via USB and I'm using
> the usbhid-ups driver. This used to work properly until recently.
>
> Now, when power goes out it keeps on going on battery potentially for
> several minutes, but, the moment line returns, I hear a click and
> power is cycled on the outlets (so every computer is rebooted
> forcily).
>
> I'm thinking about a hardware issue, but could it be that NUT is
> instructing it to do so?

I suggest an experiment:

  disconnect the USB cable to the NUT computer

  turn off power for 5 minutes

  turn power back on

and see what happens
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20221011/130493d4/attachment.sig>

From roger at rogerprice.org  Tue Oct 11 14:48:05 2022
From: roger at rogerprice.org (Roger Price)
Date: Tue, 11 Oct 2022 15:48:05 +0200 (CEST)
Subject: [Nut-upsuser] APC SmartUPS powercycles when power returns
In-Reply-To: <11f57705-7dcc-986c-7083-543dc738bbbc@netfence.it>
References: <11f57705-7dcc-986c-7083-543dc738bbbc@netfence.it>
Message-ID: <6f752e18-913c-aecf-b915-dbcb4210ed@rogerprice.org>

On Tue, 11 Oct 2022, Andrea Venturoli via Nut-upsuser wrote:

> I've got an APC SmartUPS 1500: it's connected via USB and I'm using the 
> usbhid-ups driver. This used to work properly until recently.
>
> Now, when power goes out it keeps on going on battery potentially for several 
> minutes, but, the moment line returns, I hear a click and power is cycled on 
> the outlets (so every computer is rebooted forcily).
>
> I'm thinking about a hardware issue, but could it be that NUT is instructing 
> it to do so?
>
> All I see in the logs before the nasty event is: "upsmon[89989]: UPS 
> APC at localhost on battery".
> So I don't think a low battery status was reached and/or a shutdown 
> initiated.
>
> # upsc APC
> battery.charge: 100
> battery.charge.low: 10
> battery.charge.warning: 50
...
> ups.beeper.status: enabled
> ups.delay.shutdown: 20

I do not see a line such as ? ups.delay.start: 30 ? in the upsc output.  Is this 
UPS capable of reacting to an early power-return and cancelling the shutdown?

> ups.firmware: UPS 08.8 / ID=18
> ups.mfr: American Power Conversion
> ups.mfr.date: 2014/06/20

How old is the battery?

> ups.model: Smart-UPS 1500

It's difficult to say more without knowing exactly where you are in the sequence 
of events and the timing as listed in 
https://rogerprice.org/NUT/ConfigExamples.A5.pdf chapter 2.6 The shutdown story 
for a simple server.

Roger

From ml at netfence.it  Tue Oct 11 14:55:22 2022
From: ml at netfence.it (Andrea Venturoli)
Date: Tue, 11 Oct 2022 15:55:22 +0200
Subject: [Nut-upsuser] APC SmartUPS powercycles when power returns
In-Reply-To: <rmifsfuo5yq.fsf@s1.lexort.com>
References: <11f57705-7dcc-986c-7083-543dc738bbbc@netfence.it>
 <rmifsfuo5yq.fsf@s1.lexort.com>
Message-ID: <4388433c-2f9a-49a8-cca9-5c6175f3b7cd@netfence.it>

On 10/11/22 15:17, Greg Troxel wrote:

> I suggest an experiment:
> 
>    disconnect the USB cable to the NUT computer
> 
>    turn off power for 5 minutes
> 
>    turn power back on
> 
> and see what happens

Thanks.
This is planned, but I can't be at this site before some weeks.

  bye
	av.



From roger at rogerprice.org  Tue Oct 11 15:02:50 2022
From: roger at rogerprice.org (Roger Price)
Date: Tue, 11 Oct 2022 16:02:50 +0200 (CEST)
Subject: [Nut-upsuser] APC SmartUPS powercycles when power returns
In-Reply-To: <4388433c-2f9a-49a8-cca9-5c6175f3b7cd@netfence.it>
References: <11f57705-7dcc-986c-7083-543dc738bbbc@netfence.it>
 <rmifsfuo5yq.fsf@s1.lexort.com>
 <4388433c-2f9a-49a8-cca9-5c6175f3b7cd@netfence.it>
Message-ID: <ab15223d-51d0-cb-e6e8-179a9178895@rogerprice.org>

On Tue, 11 Oct 2022, Andrea Venturoli via Nut-upsuser wrote:
> On 10/11/22 15:17, Greg Troxel wrote:
>
>> I suggest an experiment:
> Thanks.
> This is planned, but I can't be at this site before some weeks.

When you get to the site, you might be able to speed up testing by setting 
battery.charge.low to something higher than the current 10%, say 85%.

Roger


From ml at netfence.it  Tue Oct 11 15:04:45 2022
From: ml at netfence.it (Andrea Venturoli)
Date: Tue, 11 Oct 2022 16:04:45 +0200
Subject: [Nut-upsuser] APC SmartUPS powercycles when power returns
In-Reply-To: <6f752e18-913c-aecf-b915-dbcb4210ed@rogerprice.org>
References: <11f57705-7dcc-986c-7083-543dc738bbbc@netfence.it>
 <6f752e18-913c-aecf-b915-dbcb4210ed@rogerprice.org>
Message-ID: <1368af7d-2665-65b8-fd2c-9da03aad7ae4@netfence.it>

On 10/11/22 15:48, Roger Price wrote:

>> ups.firmware: UPS 08.8 / ID=18
>> ups.mfr: American Power Conversion
>> ups.mfr.date: 2014/06/20
> 
> How old is the battery?

~2.5 years.
The above date was probably not updated when it was changed.

Could a faulty battery pack produce this???
I mean, it keeps the systems up as long as line power stays off, can it 
then fail when the power returns???

I've had several such UPSes and never saw this.
However, if someone has seen this behaviour I'll try changing the batteries.
I'd just hate to do this and discover the UPS is faulty, instead.

N.B. The UPS is NOT asking for a battery replacement.





> It's difficult to say more without knowing exactly where you are in the 
> sequence of events and the timing as listed in 

1. Wall power on
2. Wall power fails
3. ...
Not 4. (batter.low was never reached); goes directly to
14. Wall power returns.
XX. Attached computers reboot instantly!!!




  bye & Thanks
	av.


From manuel.wolfshant at gmail.com  Tue Oct 11 14:44:27 2022
From: manuel.wolfshant at gmail.com (Manuel Wolfshant)
Date: Tue, 11 Oct 2022 16:44:27 +0300
Subject: [Nut-upsuser] APC SmartUPS powercycles when power returns
In-Reply-To: <11f57705-7dcc-986c-7083-543dc738bbbc@netfence.it>
References: <11f57705-7dcc-986c-7083-543dc738bbbc@netfence.it>
Message-ID: <DBCDDDA3-156E-40B4-9820-DB307DC7C7EC@gmail.com>



On October 11, 2022 3:29:46 PM GMT+03:00, Andrea Venturoli via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> wrote:
>Hello.
>
>I've got an APC SmartUPS 1500: it's connected via USB and I'm using the usbhid-ups driver. This used to work properly until recently.
>
>Now, when power goes out it keeps on going on battery potentially for several minutes, but, the moment line returns, I hear a click and power is cycled on the outlets (so every computer is rebooted forcily).
>
>I'm thinking about a hardware issue, but could it be that NUT is instructing it to do so?

Do a test with the data cable disconnected so that nut cannot "instruct" it to do anything.




>
>All I see in the logs before the nasty event is: "upsmon[89989]: UPS APC at localhost on battery".
>So I don't think a low battery status was reached and/or a shutdown initiated.

Indeed, you should also see a sequence corresponding to LB and shutdown.


wolfy


From ml at netfence.it  Tue Oct 11 15:16:25 2022
From: ml at netfence.it (Andrea Venturoli)
Date: Tue, 11 Oct 2022 16:16:25 +0200
Subject: [Nut-upsuser] APC SmartUPS powercycles when power returns
In-Reply-To: <ab15223d-51d0-cb-e6e8-179a9178895@rogerprice.org>
References: <11f57705-7dcc-986c-7083-543dc738bbbc@netfence.it>
 <rmifsfuo5yq.fsf@s1.lexort.com>
 <4388433c-2f9a-49a8-cca9-5c6175f3b7cd@netfence.it>
 <ab15223d-51d0-cb-e6e8-179a9178895@rogerprice.org>
Message-ID: <daf13abb-b4fc-318c-3d2c-2e5fa2cfdbbf@netfence.it>

On 10/11/22 16:02, Roger Price wrote:
> On Tue, 11 Oct 2022, Andrea Venturoli via Nut-upsuser wrote:
>> On 10/11/22 15:17, Greg Troxel wrote:
>>
>>> I suggest an experiment:
>> Thanks.
>> This is planned, but I can't be at this site before some weeks.
> 
> When you get to the site, you might be able to speed up testing by 
> setting battery.charge.low to something higher than the current 10%, say 
> 85%.

Sorry, but I don't understand how this might help.

Setting the above would help in testing proper shutdown through NUT.
However, this is not the problem I have.

What I think I should test is:
_ remove USB cable;
_ disconnect UPS from the power;
_ DON'T wait for shutdown;
_ reconnect UPS to power.

How would the above help?
Am I misunderstanding/forgetting something?

  bye & Thanks
	av.


From manuel.wolfshant at gmail.com  Tue Oct 11 15:18:58 2022
From: manuel.wolfshant at gmail.com (Manuel Wolfshant)
Date: Tue, 11 Oct 2022 17:18:58 +0300
Subject: [Nut-upsuser] APC SmartUPS powercycles when power returns
In-Reply-To: <1368af7d-2665-65b8-fd2c-9da03aad7ae4@netfence.it>
References: <11f57705-7dcc-986c-7083-543dc738bbbc@netfence.it>
 <6f752e18-913c-aecf-b915-dbcb4210ed@rogerprice.org>
 <1368af7d-2665-65b8-fd2c-9da03aad7ae4@netfence.it>
Message-ID: <05A9B54D-248A-40CA-BAB2-C6C7FA3F0491@gmail.com>



On October 11, 2022 5:04:45 PM GMT+03:00, Andrea Venturoli via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> wrote:
>On 10/11/22 15:48, Roger Price wrote:
>
>>> ups.firmware: UPS 08.8 / ID=18
>>> ups.mfr: American Power Conversion
>>> ups.mfr.date: 2014/06/20
>> 
>> How old is the battery?
>
>~2.5 years.
>The above date was probably not updated when it was changed.
>
>Could a faulty battery pack produce this???
Usually, not. The usual behaviour with (old|faulty) battery is sudden drop of battery capacity from 100% to 0 or close to 0 and instant death, probably without offering the protected systems to do a proper shutdown sequence. Many times the battery also pretends to recharge very fast.

>I mean, it keeps the systems up as long as line power stays off, can it then fail when the power returns???
Nope


>
>I've had several such UPSes and never saw this.
>However, if someone has seen this behaviour I'll try changing the batteries.
I've never seen this either. I do not think that batteries are at fault. OTOH I would not be surprised if an 8 yrs old UPS is defective.


wolfy
-- 

>I'd just hate to do this and discover the UPS is faulty, instead.
>
>N.B. The UPS is NOT asking for a battery replacement.
>
>
>
>
>
>> It's difficult to say more without knowing exactly where you are in the sequence of events and the timing as listed in 
>
>1. Wall power on
>2. Wall power fails
>3. ...
>Not 4. (batter.low was never reached); goes directly to
>14. Wall power returns.
>XX. Attached computers reboot instantly!!!
>
>
>
>
> bye & Thanks
>	av.
>
>_______________________________________________
>Nut-upsuser mailing list
>Nut-upsuser at alioth-lists.debian.net
>https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser


From roger at rogerprice.org  Tue Oct 11 15:21:52 2022
From: roger at rogerprice.org (Roger Price)
Date: Tue, 11 Oct 2022 16:21:52 +0200 (CEST)
Subject: [Nut-upsuser] APC SmartUPS powercycles when power returns
In-Reply-To: <daf13abb-b4fc-318c-3d2c-2e5fa2cfdbbf@netfence.it>
References: <11f57705-7dcc-986c-7083-543dc738bbbc@netfence.it>
 <rmifsfuo5yq.fsf@s1.lexort.com>
 <4388433c-2f9a-49a8-cca9-5c6175f3b7cd@netfence.it>
 <ab15223d-51d0-cb-e6e8-179a9178895@rogerprice.org>
 <daf13abb-b4fc-318c-3d2c-2e5fa2cfdbbf@netfence.it>
Message-ID: <d6bdaeb-2d17-3dfe-2448-e4c5f7e1576@rogerprice.org>

On Tue, 11 Oct 2022, Andrea Venturoli via Nut-upsuser wrote:
> On 10/11/22 16:02, Roger Price wrote:
>> On Tue, 11 Oct 2022, Andrea Venturoli via Nut-upsuser wrote:
>>> On 10/11/22 15:17, Greg Troxel wrote:
>>> 
>>>> I suggest an experiment:
>>> Thanks.
>>> This is planned, but I can't be at this site before some weeks.
>> 
>> When you get to the site, you might be able to speed up testing by setting 
>> battery.charge.low to something higher than the current 10%, say 85%.
>
> Sorry, but I don't understand how this might help.
>
> Setting the above would help in testing proper shutdown through NUT.
> However, this is not the problem I have.

I was thinking ahead to when you have fixed the current issue and are then 
testing the full setup.  I should have been clearer.

Roger


From ml at netfence.it  Tue Oct 11 16:30:57 2022
From: ml at netfence.it (Andrea Venturoli)
Date: Tue, 11 Oct 2022 17:30:57 +0200
Subject: [Nut-upsuser] APC SmartUPS powercycles when power returns
In-Reply-To: <05A9B54D-248A-40CA-BAB2-C6C7FA3F0491@gmail.com>
References: <11f57705-7dcc-986c-7083-543dc738bbbc@netfence.it>
 <6f752e18-913c-aecf-b915-dbcb4210ed@rogerprice.org>
 <1368af7d-2665-65b8-fd2c-9da03aad7ae4@netfence.it>
 <05A9B54D-248A-40CA-BAB2-C6C7FA3F0491@gmail.com>
Message-ID: <4140931d-b0c1-7c5e-b926-53584155d6e3@netfence.it>

On 10/11/22 16:18, Manuel Wolfshant wrote:

>> I mean, it keeps the systems up as long as line power stays off, can it then fail when the power returns???
> Nope

Thanks.



> OTOH I would not be surprised if an 8 yrs old UPS is defective.

No, I'm not suprised.
(Although I have a similar one, which is 16 years old and working).



  bye & Thanks
	av.


From andre.mueller at himmel-blau.com  Wed Oct 26 15:57:01 2022
From: andre.mueller at himmel-blau.com (Andre Mueller)
Date: Wed, 26 Oct 2022 16:57:01 +0200
Subject: [Nut-upsuser] =?utf-8?b?W251dC11cHN1c2Vyc10gTlVUIDIuOC4wcjMgfMKg?=
 =?utf-8?q?NUT-clients_are_loosing_connection_to_UPS_over_SNMP-driver?=
Message-ID: <ed460bad-2045-8952-f839-0e36a36049f1@himmel-blau.com>


Hello

Becoming somewhat "desperate" I configured and tested (for hours) to get 
a NUT-Server/Client 2.8.0r3 installation to work together with a 
CyberPower OLS1500 UPS over SNMP v3.

As NUT-packages for  ubuntu are still at version 2.7.4 and this 
NUT-SNMP-driver does not report very much information from the 
CyberPower UPS, I decided to compile/install from source the 2.8.0r3 
version with the following configure settings:


./configure --with-snmp --with-cgi --with-scanner  -with-docs 
--with-user=root --with-group=nut  --sysconfdir=/etc/nut/


now with version 2.8.0r3 I get over upsc full information from my ups 
(named ups00) over SNMP. Also NUT-cgi reports full information and is 
refreshed accordingly.


/usr/local/ups/bin/upsc ups00
battery.charge: 100
battery.current: 1
battery.runtime: 2880
battery.runtime.elapsed: 0
battery.voltage: 54.60
battery.voltage.nominal: 48
device.contact: Administrator
device.description: UPS SNMP Card
device.location: Server Room
device.mfr: CYBERPOWER
device.model: OLS1500ERT2UA
device.serial: 3003070Z30000042
device.type: ups
driver.name: snmp-ups
driver.parameter.pollinterval: 1
driver.parameter.port: 192.168.1.10
driver.parameter.secLevel: authPriv
driver.parameter.snmp_version: v3
driver.parameter.synchronous: auto
driver.version: 2.8.0-rc3
driver.version.data: cyberpower MIB 0.51
driver.version.internal: 1.21
input.frequency: 49.90
input.voltage: 232.50
output.current: 1
output.frequency: 49.90
output.voltage: 232.50
ups.delay.reboot: 0
ups.delay.shutdown: 180
ups.delay.start: 0
ups.firmware: OS02RV07
ups.load: 17
ups.mfr: CYBERPOWER
ups.model: OLS1500ERT2UA
ups.serial: 3003070Z30000042
ups.status:


Also the NUT-Server (v2.8.0r3) seems to works correct and 3 NUT-clients 
(1 local, 2 remote) can login correctly to the NUT-Server and to the ups00.


nut-server[1069]: User upsmon at 127.0.0.1 logged into UPS [ups00]
upsd[1069]: User upsmon at 127.0.0.1 logged into UPS [ups00]
nut-server[1069]: User upsmon at 192.168.1.211 logged into UPS [ups00]
upsd[1069]: User upsmon at 192.168.1.211 logged into UPS [ups00]
nut-server[1069]: User upsmon at 192.168.1.11 logged into UPS [ups00]
upsd[1069]: User upsmon at 192.168.1.11 logged into UPS [ups00]


Unfortunately all NUT-clients (also the local NUT-client) are reporting 
directly after the first refresh and then continuously, that they have 
lost connenctions to the ups00 but they are still loggedin to the 
NUT-Server.

...
nut-monitor[1078]: UPS ups00 at localhost is unavailable
nut-monitor[29503]: Network UPS Tools upsmon 2.8.0-rc3
...

So my question is, what could be "wrong" in configuration and/or 
installation, that all clients (local or remote) are reporting that they 
have lost connection to the ups00 and that it is not unavailable?


Many thanks in advance for any hint, best









From jimklimov+nut at gmail.com  Wed Oct 26 21:24:25 2022
From: jimklimov+nut at gmail.com (Jim Klimov)
Date: Wed, 26 Oct 2022 22:24:25 +0200
Subject: [Nut-upsuser] [nut-upsusers] NUT 2.8.0r3 | NUT-clients are
 loosing connection to UPS over SNMP-driver
In-Reply-To: <ed460bad-2045-8952-f839-0e36a36049f1@himmel-blau.com>
References: <ed460bad-2045-8952-f839-0e36a36049f1@himmel-blau.com>
Message-ID: <CAJYg8vK1s=Qdouevoffvo_ZMV8+o0SdOnCyRqDXhNkATvP-buQ@mail.gmail.com>

On the road now so gotta come back to main question later, but for now -
why 2.8.0-rc3 (not "r3")? There is a newer final release, or current
master... just asking.

Notably, there was a fix in master last week or so that moght help woth
some broken large queries for SNMPv2/v3... No idea if that's your case
though. Error messages from clients might help.

Jim

On Wed, Oct 26, 2022, 17:57 Andre Mueller via Nut-upsuser <
nut-upsuser at alioth-lists.debian.net> wrote:

>
> Hello
>
> Becoming somewhat "desperate" I configured and tested (for hours) to get
> a NUT-Server/Client 2.8.0r3 installation to work together with a
> CyberPower OLS1500 UPS over SNMP v3.
>
> As NUT-packages for  ubuntu are still at version 2.7.4 and this
> NUT-SNMP-driver does not report very much information from the
> CyberPower UPS, I decided to compile/install from source the 2.8.0r3
> version with the following configure settings:
>
>
> ./configure --with-snmp --with-cgi --with-scanner  -with-docs
> --with-user=root --with-group=nut  --sysconfdir=/etc/nut/
>
>
> now with version 2.8.0r3 I get over upsc full information from my ups
> (named ups00) over SNMP. Also NUT-cgi reports full information and is
> refreshed accordingly.
>
>
> /usr/local/ups/bin/upsc ups00
> battery.charge: 100
> battery.current: 1
> battery.runtime: 2880
> battery.runtime.elapsed: 0
> battery.voltage: 54.60
> battery.voltage.nominal: 48
> device.contact: Administrator
> device.description: UPS SNMP Card
> device.location: Server Room
> device.mfr: CYBERPOWER
> device.model: OLS1500ERT2UA
> device.serial: 3003070Z30000042
> device.type: ups
> driver.name: snmp-ups
> driver.parameter.pollinterval: 1
> driver.parameter.port: 192.168.1.10
> driver.parameter.secLevel: authPriv
> driver.parameter.snmp_version: v3
> driver.parameter.synchronous: auto
> driver.version: 2.8.0-rc3
> driver.version.data: cyberpower MIB 0.51
> driver.version.internal: 1.21
> input.frequency: 49.90
> input.voltage: 232.50
> output.current: 1
> output.frequency: 49.90
> output.voltage: 232.50
> ups.delay.reboot: 0
> ups.delay.shutdown: 180
> ups.delay.start: 0
> ups.firmware: OS02RV07
> ups.load: 17
> ups.mfr: CYBERPOWER
> ups.model: OLS1500ERT2UA
> ups.serial: 3003070Z30000042
> ups.status:
>
>
> Also the NUT-Server (v2.8.0r3) seems to works correct and 3 NUT-clients
> (1 local, 2 remote) can login correctly to the NUT-Server and to the ups00.
>
>
> nut-server[1069]: User upsmon at 127.0.0.1 logged into UPS [ups00]
> upsd[1069]: User upsmon at 127.0.0.1 logged into UPS [ups00]
> nut-server[1069]: User upsmon at 192.168.1.211 logged into UPS [ups00]
> upsd[1069]: User upsmon at 192.168.1.211 logged into UPS [ups00]
> nut-server[1069]: User upsmon at 192.168.1.11 logged into UPS [ups00]
> upsd[1069]: User upsmon at 192.168.1.11 logged into UPS [ups00]
>
>
> Unfortunately all NUT-clients (also the local NUT-client) are reporting
> directly after the first refresh and then continuously, that they have
> lost connenctions to the ups00 but they are still loggedin to the
> NUT-Server.
>
> ...
> nut-monitor[1078]: UPS ups00 at localhost is unavailable
> nut-monitor[29503]: Network UPS Tools upsmon 2.8.0-rc3
> ...
>
> So my question is, what could be "wrong" in configuration and/or
> installation, that all clients (local or remote) are reporting that they
> have lost connection to the ups00 and that it is not unavailable?
>
>
> Many thanks in advance for any hint, best
>
>
>
>
>
>
>
>
> _______________________________________________
> 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/20221026/de2a4ec4/attachment.htm>

From andre.mueller at himmel-blau.com  Thu Oct 27 17:39:23 2022
From: andre.mueller at himmel-blau.com (Andre Mueller)
Date: Thu, 27 Oct 2022 18:39:23 +0200
Subject: [Nut-upsuser] NUT 2.8.0r3 | NUT-clients are loosing connection
 to UPS over SNMP-driver
In-Reply-To: <CAJYg8vK1s=Qdouevoffvo_ZMV8+o0SdOnCyRqDXhNkATvP-buQ@mail.gmail.com>
References: <ed460bad-2045-8952-f839-0e36a36049f1@himmel-blau.com>
 <CAJYg8vK1s=Qdouevoffvo_ZMV8+o0SdOnCyRqDXhNkATvP-buQ@mail.gmail.com>
Message-ID: <a85be368-9f71-bcb2-c99b-0b451b47cd54@himmel-blau.com>


Hello Jim

Many thanks for your reply.

As I am on a Ubuntu system there are at that time no nut-packages for 
version 2.8.0. And as I wanted to avoid to get a mess with dependencies 
from the Debian nut 2.8.0-4 packages, I decided to compile from the 
networkupstools.org nut source archive 
(https://github.com/networkupstools/nut-source-archive/tree/master/2.8/) 
where only version 2.8.0-rc3 (april 2022) is available.

Now I have installed the Debian nut 2.8.0-4 packages (bookworm) manually 
to my Ubuntu system. So far the nut 2.8.0-4 services etc. are working 
correctly, but the problem remains the same, that upsmon/nut-clients are 
reporting, that they have lost connection to the ups they are already 
logged in. I have installed those Debian packages manually:

libltdl7_2.4.7-4_amd64.deb
libnutscan2_2.8.0-4_amd64.deb
libsnmp40_5.9.3+dfsg-1+b1_amd64.deb
libupsclient6_2.8.0-4_amd64.deb
nut_2.8.0-4_all.deb
nut-cgi_2.8.0-4_amd64.deb
nut-client_2.8.0-4_amd64.deb
nut-monitor_2.8.0-4_all.deb
nut-server_2.8.0-4_amd64.deb
nut-snmp_2.8.0-4_amd64.deb
python3-nut_2.8.0-4_all.deb


Instead upsd is working correctly for the ups (named ups00), nut-cgi also:

nut-server[1132]: Connected to UPS [ups00]: snmp-ups-ups00
upsd[1132]: Connected to UPS [ups00]: snmp-ups-ups00
nut-server[1132]: Running as foreground process, not saving a PID file
nut-server[1132]: User upsmon at 127.0.0.1 logged into UPS [ups00]
upsd[1132]: Running as foreground process, not saving a PID file
upsd[1132]: User upsmon at 127.0.0.1 logged into UPS [ups00]
nut-server[1132]: User upsmon at 192.168.1.11 logged into UPS [ups00]
upsd[1132]: User upsmon at 192.168.1.11 logged into UPS [ups00]
nut-server[1132]: User upsmon at 192.168.1.211 logged into UPS [ups00]
upsd[1132]: User upsmon at 192.168.1.211 logged into UPS [ups00]

upsc -L
Init SSL without certificate database
ups00: upsmy.mydomain.net

upsc -c ups00
Init SSL without certificate database
192.168.1.211
192.168.1.11
127.0.0.1

upsc ups00
Init SSL without certificate database
battery.charge: 100
battery.current: 0.90
battery.runtime: 2880
battery.runtime.elapsed: 0
battery.voltage: 54.60
battery.voltage.nominal: 48
device.contact: Administrator
device.description: UPS SNMP Card
device.location: Server Room
device.mfr: CYBERPOWER
device.model: OLS1500ERT2UA
device.serial: 3003070Z30000042
device.type: ups
driver.name: snmp-ups
driver.parameter.pollinterval: 1
driver.parameter.port: upsmy.mydomain.net
driver.parameter.secLevel: authPriv
driver.parameter.snmp_version: v3
driver.parameter.synchronous: auto
driver.version: 2.8.0
driver.version.data: cyberpower MIB 0.51
driver.version.internal: 1.21
input.frequency: 50
input.voltage: 233.50
output.current: 0.90
output.frequency: 50
output.voltage: 233.50
ups.delay.reboot: 0
ups.delay.shutdown: 180
ups.delay.start: 0
ups.firmware: OS02RV07
ups.load: 17
ups.mfr: CYBERPOWER
ups.model: OLS1500ERT2UA
ups.serial: 3003070Z30000042
ups.status:


status/log from upsmon is (still):
...
nut-monitor[1135]: UPS ups00 at localhost is unavailable
nut-monitor[2130]: Network UPS Tools upsmon 2.8.0
...

or detailed from upsmon -D -D -D:


upsmon -D -D -D
Network UPS Tools upsmon 2.8.0
    0.000000	fopen /run/nut/upsmon.pid: No such file or directory
    0.000614	Could not find PID file to see if previous upsmon instance 
is already running!

    0.001522	Using power down flag file /etc/killpower
    0.002237	UPS: ups00 at localhost (primary) (power value 1)
    0.002844	[D1] debug level is '3'
    0.003441	[D1] debug level is '3'
    0.004638	[D1] Saving PID 2295 into /run/nut/upsmon.pid
Init SSL without certificate database
    0.008229	[D1] Trying to connect to UPS [ups00 at localhost]
    0.009241	[D1] Logged into UPS ups00 at localhost
    0.009427	[D2] pollups: ups00 at localhost
    0.009456	[D3] get_var: ups00 at localhost / status
    0.009579	[D2] parse_status: []
    0.009603	[D2] do_notify: ntype 0x0005 (COMMBAD)
    0.009621	Communications with UPS ups00 at localhost lost
    0.009808	[D3] Current power value: 1
    0.009892	[D3] Minimum power value: 1
 

Broadcast message from root at localhost (pts/1) (Thu Oct 27 18:35:07
 

Communications with UPS ups00 at localhost lost 

 

 

Broadcast message from root at localhost (pts/1) (Thu Oct 27 18:35:07
 

Communications with UPS ups00 at localhost lost 

 

    5.010023	[D2] pollups: ups00 at localhost
    5.010128	[D3] get_var: ups00 at localhost / status
    5.010292	[D2] parse_status: []
    5.010316	[D2] do_notify: ntype 0x0008 (NOCOMM)
    5.010330	UPS ups00 at localhost is unavailable
    5.010618	[D3] Current power value: 1
    5.010690	[D3] Minimum power value: 1
 

Broadcast message from root at localhost (pts/1) (Thu Oct 27 18:35:12
 

UPS ups00 at localhost is unavailable 

 

 

Broadcast message from root at localhost (pts/1) (Thu Oct 27 18:35:12
 

UPS ups00 at localhost is unavailable 

 

   10.010912	[D2] pollups: ups00 at localhost
   10.010955	[D3] get_var: ups00 at localhost / status
   10.011163	[D2] parse_status: []
   10.011184	[D3] Current power value: 1
   10.011216	[D3] Minimum power value: 1
   15.011440	[D2] pollups: ups00 at localhost
   15.011485	[D3] get_var: ups00 at localhost / status
   15.011651	[D2] parse_status: []
   15.011676	[D3] Current power value: 1
   15.011691	[D3] Minimum power value: 1

...

above log flow is the same on other connected nut-clients.



Many thanks again

Andr?


Am 26.10.2022 um 22:24 schrieb Jim Klimov:
> On the road now so gotta come back to main question later, but for now - 
> why 2.8.0-rc3 (not "r3")? There is a newer final release, or current 
> master... just asking.
> 
> Notably, there was a fix in master last week or so that moght help woth 
> some broken large queries for SNMPv2/v3... No idea if that's your case 
> though. Error messages from clients might help.
> 
> Jim
> 
> On Wed, Oct 26, 2022, 17:57 Andre Mueller via Nut-upsuser 
> <nut-upsuser at alioth-lists.debian.net 
> <mailto:nut-upsuser at alioth-lists.debian.net>> wrote:
> 
> 
>     Hello
> 
>     Becoming somewhat "desperate" I configured and tested (for hours) to
>     get
>     a NUT-Server/Client 2.8.0r3 installation to work together with a
>     CyberPower OLS1500 UPS over SNMP v3.
> 
>     As NUT-packages for? ubuntu are still at version 2.7.4 and this
>     NUT-SNMP-driver does not report very much information from the
>     CyberPower UPS, I decided to compile/install from source the 2.8.0r3
>     version with the following configure settings:
> 
> 
>     ./configure --with-snmp --with-cgi --with-scanner? -with-docs
>     --with-user=root --with-group=nut? --sysconfdir=/etc/nut/
> 
> 
>     now with version 2.8.0r3 I get over upsc full information from my ups
>     (named ups00) over SNMP. Also NUT-cgi reports full information and is
>     refreshed accordingly.
> 
> 
>     /usr/local/ups/bin/upsc ups00
>     battery.charge: 100
>     battery.current: 1
>     battery.runtime: 2880
>     battery.runtime.elapsed: 0
>     battery.voltage: 54.60
>     battery.voltage.nominal: 48
>     device.contact: Administrator
>     device.description: UPS SNMP Card
>     device.location: Server Room
>     device.mfr: CYBERPOWER
>     device.model: OLS1500ERT2UA
>     device.serial: 3003070Z30000042
>     device.type: ups
>     driver.name <http://driver.name>: snmp-ups
>     driver.parameter.pollinterval: 1
>     driver.parameter.port: 192.168.1.10
>     driver.parameter.secLevel: authPriv
>     driver.parameter.snmp_version: v3
>     driver.parameter.synchronous: auto
>     driver.version: 2.8.0-rc3
>     driver.version.data: cyberpower MIB 0.51
>     driver.version.internal: 1.21
>     input.frequency: 49.90
>     input.voltage: 232.50
>     output.current: 1
>     output.frequency: 49.90
>     output.voltage: 232.50
>     ups.delay.reboot: 0
>     ups.delay.shutdown: 180
>     ups.delay.start: 0
>     ups.firmware: OS02RV07
>     ups.load: 17
>     ups.mfr: CYBERPOWER
>     ups.model: OLS1500ERT2UA
>     ups.serial: 3003070Z30000042
>     ups.status:
> 
> 
>     Also the NUT-Server (v2.8.0r3) seems to works correct and 3 NUT-clients
>     (1 local, 2 remote) can login correctly to the NUT-Server and to the
>     ups00.
> 
> 
>     nut-server[1069]: User upsmon at 127.0.0.1 <mailto:upsmon at 127.0.0.1>
>     logged into UPS [ups00]
>     upsd[1069]: User upsmon at 127.0.0.1 <mailto:upsmon at 127.0.0.1> logged
>     into UPS [ups00]
>     nut-server[1069]: User upsmon at 192.168.1.211
>     <mailto:upsmon at 192.168.1.211> logged into UPS [ups00]
>     upsd[1069]: User upsmon at 192.168.1.211 <mailto:upsmon at 192.168.1.211>
>     logged into UPS [ups00]
>     nut-server[1069]: User upsmon at 192.168.1.11
>     <mailto:upsmon at 192.168.1.11> logged into UPS [ups00]
>     upsd[1069]: User upsmon at 192.168.1.11 <mailto:upsmon at 192.168.1.11>
>     logged into UPS [ups00]
> 
> 
>     Unfortunately all NUT-clients (also the local NUT-client) are reporting
>     directly after the first refresh and then continuously, that they have
>     lost connenctions to the ups00 but they are still loggedin to the
>     NUT-Server.
> 
>     ...
>     nut-monitor[1078]: UPS ups00 at localhost is unavailable
>     nut-monitor[29503]: Network UPS Tools upsmon 2.8.0-rc3
>     ...
> 
>     So my question is, what could be "wrong" in configuration and/or
>     installation, that all clients (local or remote) are reporting that
>     they
>     have lost connection to the ups00 and that it is not unavailable?
> 
> 
>     Many thanks in advance for any hint, best
> 
> 
> 
> 
>