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 <[email protected]> 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 <[email protected]> > 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@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 > >
_______________________________________________ Nut-upsuser mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
