[Nut-upsuser] NUT can't connect to USB UPS on OpenBSD

[Jim Klimov]

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>