<div dir="ltr"><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>Hope this helps,</div><div>Jim Klimov<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 4, 2022 at 1:03 AM Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Glad you got it working.<br>
<br>
<br>
Marc-André Harbec <<a href="mailto:maharbec@gmail.com" target="_blank">maharbec@gmail.com</a>> writes:<br>
<br>
> Also, I found I had to manually start the USB driver. In my case:<br>
> `usbhid-ups`. I don't know if it's something that needs to be done on<br>
> all platforms (or it's OpenBSD specific), but I haven't read anything<br>
> on this in the official documentation. The `upsd` daemon won't start<br>
> if the driver is not already running, and it won't spawn it itself. I<br>
> had too create my own service file for it:<br>
><br>
>     $ cat /etc/rc.d/usbhid_ups<br>
>     #!/bin/ksh<br>
<br>
In pkgsrc (and hence on NetBSD), there is a /etc/rc.d/upsdriver and that<br>
seems to run something that looks in /usr/pkg/etc/nut/ups.conf.   I have<br>
a Best unit and that starts it at boot.   So you could perhaps create a<br>
generic driver rcfile and use 'upsdrvctl start'.<br>
_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@alioth-lists.debian.net" target="_blank">Nut-upsuser@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
</blockquote></div>