Thanks for the tip. Feel free to share the details in NUT Wiki or post a PR
for `srcipts/...` (either existing or a new subdirectory if the
init-scripts or equivalent that you have is rather Devuan-specific).
Does the distro have any mechanism equivalent to systemd udev, to assign
devfs node permissions as devices are (re)discovered? NUT sources generate
configurations for quite a few such sub-systems (devd, upower, hotplug, BSD
quirks...) and it may be possible to extend tools/nut-usbinfo.pl to add
more. Some such subsystems are able to also react to HW changes by running
custom handler programs - e.g. a restart of a NUT driver, which may also
help.
Alternately, IF the problem is just about permissions and not so much the
USB layer, this can be checked (and/or worked around) by running the driver
program as `root` without dropping privileges (`-u root` or `-x user=root`
on command line, or `user=root` in `ups.conf`). This is not something
normally recommended to keep for a long time (the fewer privileged
processes are running - the better) but can at least confirm or rule out
some failure modes.
Hope this helps,
Jim Klimov
On Fri, May 16, 2025 at 10:40?AM Alexey Korobeinikov <alexey at
fseafood.com>
wrote:
> I observed this behavior with several Powercom UPSs (BNT 400/600/1000) new
> and old on different computers. It didn't matter. Even replacing USB
cables
> or switching to another port didn't give stable results. Only usbreset
and
> immediately restarting/starting the service gave about 90% result.
> Therefore, I slightly changed the startup script in the system so that if
> the required VendorID:DeviceID was available, this port would be restarted
> and NUT would be started immediately.
>
> 16.05.2025 11:16, Jim Klimov:
>
> Well, it is always (quite) possible that the hardware is... subpar,
> leading to loss of connection.
>
> Try a different USB port (maybe on a different MoBo hub if there's a
> choice), different cable (check if you have a shielded/grounded one to
> minimize EMI noise), revise if there are any motors (fridges, dishwashers)
> or luminescent lighting starters etc. nearby on the electric line and
> physically near the cabling, etc.
>
> Maybe there is some vendor-provided way to update the UPS firmware?
>
> You mentioned the device may be from 2017 - maybe it collected a lot of
> dust over time and just overheats or has random static discharge inside -
> so some internal physical maintenance with a toothbrush, vacuum cleaner,
> and proper electrotechnical hygiene for your safety could also do wonders?
> On similar note, is the battery also as old? PbAc tend to not live that
> long, maybe replacing it could stabilize things.
>
> Jim
>
>
> On Fri, May 16, 2025 at 9:41?AM Alexey Korobeinikov <alexey at
fseafood.com>
> wrote:
>
>> On Devuan Linux daedalus (no systemd).
>> I try to manualy start nut-service or just usbhid-ups drivers. I have
>> observed such problems before. They were solved by usbreset on this
>> device (0d9f:0004) and immediately launch nut-service/drivers. But
>> sometimes it wasn't necessary to do that.
>>
>>
>> 16.05.2025 00:01, Jim Klimov:
>>
>> Are you on Linux? Did you check if NDE created a service instance like
>> `nut-driver at UPS` that starts automatically and your manually started
>> driver instance tries to steal from it?
>>
>> *
>>
https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE)
>>
>> Jim
>>
>>
>> --
>> ? ???????
>> ???????????? ???????
>> ????????? ?????????????
>>
>> ??? "??????? ?????"
>> ???. ?????????? 152, ??? ?????? ???????
>> ???????? ???????, 07442
>> ?.+38 044 495-88-00
>> ??.6101
>> ?.+38 067 994-40-48
>>
>>
> --
> ? ???????
> ???????????? ???????
> ????????? ?????????????
>
> ??? "??????? ?????"
> ???. ?????????? 152, ??? ?????? ???????
> ???????? ???????, 07442
> ?.+38 044 495-88-00
> ??.6101
> ?.+38 067 994-40-48
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20250516/6fb3c8dd/attachment-0001.htm>