Re: [Nut-upsuser] PR to test for users of Qx devices (blazer and nutdrv_qx)
Thanks! So, comparing this with the January report -- there are no substantial changes in device discovery process and the collected info. However, the 10K seems to actually report most of the data which we have to "guesstimate" in other cases. Hoping somebody else with QX devices would chime in then :) Jim On Wed, Sep 13, 2023 at 3:26 PM d tbsky wrote: > jim Klimov > > > > Hello all, > > > > Had another hard look at the PR for QX device voltage/charge/runtime > fixes for some broken use-cases (AND hoping to not introduce problems for > cases that were not broken), and hopefully found and rolled back the change > which in fact introduced the strangeness found in our winter round of > tests. Then the year was busy... > > > > As before, the context for this is: > > * issue https://github.com/networkupstools/nut/issues/1279 > > * PR https://github.com/networkupstools/nut/pull/1652 > > * PR source git branch (code to build for tests) > https://github.com/jimklimov/nut/tree/issue-1279 > > * > https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests > suggests how to quickly build and > > Hi: >one of our voltronic ups caught fire last year. so we abandoned > them and bought APC. now I have only one 10KV ups to test. It's sad > because I like nutdrv_qx driver. APC microlink is too bad since nut > doesn't support it. there is only modbus with apcupsd driver. > >BTW I saw an APC ups discussion at nut-upsdev about "SRVS1KI"(can > not reply, not subscribed to that list) . I have that easy-ups series. > nut can support them well with apcsmart driver. normally we should > attach it via serial cable. if you attach the ups with usb cable, you > will see "XR21V1410" which is a usb-serial converter. linux kernel > 5.15 seems include the driver. or you will need to compile the > driver(xr_usb_serial_common) yourself and get "/dev/ttyXRUSB0" to use > as an serial port. I do that because we lost serial cable at a remote > site and forced to use the usb cable. > > > ./nutdrv_qx -a ftups -u root -DD -d1 > Network UPS Tools - Generic Q* USB/Serial driver 0.35 > (2.8.0-2359-g6c0032e52) > USB communication driver (libusb 1.0) 0.45 >0.00 [D1] Network UPS Tools version 2.8.0-2359-g6c0032e52 > (release/snapshot of 2.8.0.1) built with gcc (GCC) 11.3.1 20221121 > (Red Hat 11.3.1-4) and configured with flags: --enable-Wcolor > --enable-keep_nut_report_featu > re --with-all=auto --with-cgi=auto > --with-serial=auto --with-dev=auto --with-doc=skip > --with-nut_monitor=auto --with-pynut=auto > --disable-force-nut-version-header --enable-check-NIT > --enable-maintainer-mode >0.11 [D1] debug level is '6' >0.14 [D5] send_to_all: SETINFO driver.debug "6" >0.18 [D5] send_to_all: SETFLAGS driver.debug RW NUMBER >0.000815 [D1] Succeeded to become_user(root): now UID=0 GID=0 >0.000822 [D5] send_to_all: SETINFO device.type "ups" >0.000825 [D5] send_to_all: SETINFO driver.state "init.device" >0.000827 [D1] upsdrv_initups... >0.003147 [D2] Checking device 1 of 11 (8087/8000) >0.057855 [D2] - VendorID: 8087 >0.057861 [D2] - ProductID: 8000 >0.057862 [D2] - Manufacturer: unknown >0.057864 [D2] - Product: unknown >0.057865 [D2] - Serial Number: unknown >0.057867 [D2] - Bus: 002 >0.057868 [D2] - Device: 002 >0.057870 [D2] - Device release number: 0005 >0.057873 [D2] Trying to match device >0.057875 [D3] match_function_regex: matching a device... >0.057888 [D2] Device does not match - skipping >0.071830 [D2] Checking device 2 of 11 (1D6B/0002) >0.078881 [D2] - VendorID: 1d6b >0.078885 [D2] - ProductID: 0002 >0.078887 [D2] - Manufacturer: Linux 5.14.0-162.23.1.el9_1.x86_64 > ehci_hcd >0.07 [D2] - Product: EHCI Host Controller >0.078890 [D2] - Serial Number: :00:1d.0 >0.078891 [D2] - Bus: 002 >0.078893 [D2] - Device: 001 >0.078894 [D2] - Device release number: 0514 >0.078897 [D2] Trying to match device >0.078898 [D3] match_function_regex: matching a device... >0.078912 [D2] Device does not match - skipping >0.091359 [D2] Checking device 3 of 11 (8087/8008) >0.145626 [D2] - VendorID: 8087 >0.145635 [D2] - ProductID: 8008 >0.145637 [D2] - Manufacturer: unknown >0.145638 [D2] - Product: unknown >0.145640 [D2] - Serial Number: unknown >0.145641 [D2] - Bus: 001 >0.145643 [D2] - Device: 002 >0.145645 [D2] - Device release number: 0005 >0.145648 [D2] Trying to match device >0.145661 [D3] match_function_regex: matching a device... >0.145664 [D2] Device does not match - skipping >0.159837 [D2] Checking device 4 of 11 (1D6B/0002) >0.166862 [D2] - VendorID: 1d6b >0.166867 [D2] -
Re: [Nut-upsuser] Multiple battery levels to trigger actions?
Hello, I think this should be possible, probably with dummy-ups or clone* drivers and respective override.* definitions in the "secondary drivers" So if something does not work here, I'm ready to consider it a bug. Can you post samples of config and logs (are there any errors?) One thing that comes to mind quickly: with NUT 2.8.0+ we deliver a new `nut-driver-enumerator` (script and service) which when enabled, looks at ups.conf contents and its real-time changes, and can generate unit instances for nut-driver@SectionName (a bit more complicated than that in the most general case, not all name patterns are valid for systemd or SMF that this approach supports - can be MD5 hashes of the section name then). As part of such definitions, it describes "After" and "Wants" dependencies based on driver type (e.g. not all of them are tied to networking). A possible caveat here is that one driver depending on another, and depending on an upsd data server, while any driver generally also being a dependency for upsd to start - this may require manual addition of systemd "drop-in" files to untangle the dependencies. Note that this entanglement concerns primarily the service definitions. Daemons themselves are relatively independent, with `upsd` capable of polling the FS if socket files appear so they would pick up a driver (re-)started after the data server began running. Nowadays there is also an option for `upsd` to allow starting if currently there are no devices listed in `ups.conf`, so it can be reloaded with a signal later - after the file becomes populated (e.g. to behave predictably on a newly deployed monitoring appliance). Generally a driver also can start and live independently of `upsd` appearing or going away. A `dummy-ups` or `clone*` driver might however refuse to start if it can not read its data source which it relays further - e.g. if the `upsd` is not yet running or serving the "original" driver data (snmp-ups in your case). Something to try here is to check if such units do exist, and if yes - to start them (or even for experiments - directly start the daemons via command-line, without a service unit). If I guess the default situation correctly, after boot you would have snmp-ups running, and possibly upsd (if a failed cloning driver did not preclude its start as the nut-server systemd unit). Hopefully after some time any failed clone driver units would retry starting after a quiet timeout, and would find the upsd and snmp-ups's data on it. If however systemd decides there is a dependency loop, it might decide to never (re-)start something, in order to avoid the loop - either clone driver units or nut-server. If such simple attempts prove that the daemons and configurations CAN still work like this (no regression in NUT itself), then a drop-in file for each clone driver unit like /etc/systemd/system/nut-driver@dummy1.service/customdeps.conf could be used (see man pages for your systemd version to be sure about the syntax) to e.g. remove the backwards "Install" dependency like `WantedBy=nut-server.service` (probably by specifying a blank `WantedBy=`) so that the loop would be no more, and ensuring there is a "Service" section dependency set of `Wants=nut-server.service` and `After=nut-server.service` - so this clone driver would only try to start when it can actually succeed. Use `systemd daemon-reload` to apply edits. Hope this helps, Jim Klimov On Wed, Sep 13, 2023 at 9:30 AM Steffen Grunewald < steffen.grunew...@aei.mpg.de> wrote: > Good morning NUTcrackers, > > several years ago, I had a setup that used the SNMP driver to collect data > from a networked UPS and act as a source for multiple "secondary" drivers > that each had a different battery level to trigger various actions, e.g. > at 70% shut down some services, at 50% freeze the batch system and at 30% > switch off everything but the spinning disks (leave JBODs running, change > runlevel to 1). > > My attempts to clone the old setting for a recent version of NUT (2.8.0, > backported from sid a few months ago) failed to start the set of drivers, > so something must have changed while I wasn't looking. > > Is this approach still possible with NUT 2.8.x, and may I learn from > someone who is running such a setup? > > Thanks in advance, > Steffen > > -- > Steffen Grunewald, Cluster Administrator > Max Planck Institute for Gravitational Physics (Albert Einstein Institute) > Am Mühlenberg 1 * D-14476 Potsdam-Golm * Germany > ~~~ > Fon: +49-331-567 7274 > Mail: steffen.grunewald(at)aei.mpg.de > ~~~ > > ___ > Nut-upsuser mailing list > Nut-upsuser@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser > ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] PR to test for users of Qx devices (blazer and nutdrv_qx)
jim Klimov > > Hello all, > > Had another hard look at the PR for QX device voltage/charge/runtime fixes > for some broken use-cases (AND hoping to not introduce problems for cases > that were not broken), and hopefully found and rolled back the change which > in fact introduced the strangeness found in our winter round of tests. Then > the year was busy... > > As before, the context for this is: > * issue https://github.com/networkupstools/nut/issues/1279 > * PR https://github.com/networkupstools/nut/pull/1652 > * PR source git branch (code to build for tests) > https://github.com/jimklimov/nut/tree/issue-1279 > * > https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests > suggests how to quickly build and Hi: one of our voltronic ups caught fire last year. so we abandoned them and bought APC. now I have only one 10KV ups to test. It's sad because I like nutdrv_qx driver. APC microlink is too bad since nut doesn't support it. there is only modbus with apcupsd driver. BTW I saw an APC ups discussion at nut-upsdev about "SRVS1KI"(can not reply, not subscribed to that list) . I have that easy-ups series. nut can support them well with apcsmart driver. normally we should attach it via serial cable. if you attach the ups with usb cable, you will see "XR21V1410" which is a usb-serial converter. linux kernel 5.15 seems include the driver. or you will need to compile the driver(xr_usb_serial_common) yourself and get "/dev/ttyXRUSB0" to use as an serial port. I do that because we lost serial cable at a remote site and forced to use the usb cable. > ./nutdrv_qx -a ftups -u root -DD -d1 Network UPS Tools - Generic Q* USB/Serial driver 0.35 (2.8.0-2359-g6c0032e52) USB communication driver (libusb 1.0) 0.45 0.00 [D1] Network UPS Tools version 2.8.0-2359-g6c0032e52 (release/snapshot of 2.8.0.1) built with gcc (GCC) 11.3.1 20221121 (Red Hat 11.3.1-4) and configured with flags: --enable-Wcolor --enable-keep_nut_report_featu re --with-all=auto --with-cgi=auto --with-serial=auto --with-dev=auto --with-doc=skip --with-nut_monitor=auto --with-pynut=auto --disable-force-nut-version-header --enable-check-NIT --enable-maintainer-mode 0.11 [D1] debug level is '6' 0.14 [D5] send_to_all: SETINFO driver.debug "6" 0.18 [D5] send_to_all: SETFLAGS driver.debug RW NUMBER 0.000815 [D1] Succeeded to become_user(root): now UID=0 GID=0 0.000822 [D5] send_to_all: SETINFO device.type "ups" 0.000825 [D5] send_to_all: SETINFO driver.state "init.device" 0.000827 [D1] upsdrv_initups... 0.003147 [D2] Checking device 1 of 11 (8087/8000) 0.057855 [D2] - VendorID: 8087 0.057861 [D2] - ProductID: 8000 0.057862 [D2] - Manufacturer: unknown 0.057864 [D2] - Product: unknown 0.057865 [D2] - Serial Number: unknown 0.057867 [D2] - Bus: 002 0.057868 [D2] - Device: 002 0.057870 [D2] - Device release number: 0005 0.057873 [D2] Trying to match device 0.057875 [D3] match_function_regex: matching a device... 0.057888 [D2] Device does not match - skipping 0.071830 [D2] Checking device 2 of 11 (1D6B/0002) 0.078881 [D2] - VendorID: 1d6b 0.078885 [D2] - ProductID: 0002 0.078887 [D2] - Manufacturer: Linux 5.14.0-162.23.1.el9_1.x86_64 ehci_hcd 0.07 [D2] - Product: EHCI Host Controller 0.078890 [D2] - Serial Number: :00:1d.0 0.078891 [D2] - Bus: 002 0.078893 [D2] - Device: 001 0.078894 [D2] - Device release number: 0514 0.078897 [D2] Trying to match device 0.078898 [D3] match_function_regex: matching a device... 0.078912 [D2] Device does not match - skipping 0.091359 [D2] Checking device 3 of 11 (8087/8008) 0.145626 [D2] - VendorID: 8087 0.145635 [D2] - ProductID: 8008 0.145637 [D2] - Manufacturer: unknown 0.145638 [D2] - Product: unknown 0.145640 [D2] - Serial Number: unknown 0.145641 [D2] - Bus: 001 0.145643 [D2] - Device: 002 0.145645 [D2] - Device release number: 0005 0.145648 [D2] Trying to match device 0.145661 [D3] match_function_regex: matching a device... 0.145664 [D2] Device does not match - skipping 0.159837 [D2] Checking device 4 of 11 (1D6B/0002) 0.166862 [D2] - VendorID: 1d6b 0.166867 [D2] - ProductID: 0002 0.166868 [D2] - Manufacturer: Linux 5.14.0-162.23.1.el9_1.x86_64 ehci_hcd 0.166870 [D2] - Product: EHCI Host Controller 0.166871 [D2] - Serial Number: :00:1a.0 0.166873 [D2] - Bus: 001 0.166874 [D2] - Device: 001 0.166876 [D2] - Device release number: 0514 0.166878 [D2] Trying to match device 0.166880 [D3] match_function_regex: matching a device... 0.166894 [D2] Device does not match - skipping 0.179366 [D2] Checking device 5 of 11 (1D6B/0003)
[Nut-upsuser] Multiple battery levels to trigger actions?
Good morning NUTcrackers, several years ago, I had a setup that used the SNMP driver to collect data from a networked UPS and act as a source for multiple "secondary" drivers that each had a different battery level to trigger various actions, e.g. at 70% shut down some services, at 50% freeze the batch system and at 30% switch off everything but the spinning disks (leave JBODs running, change runlevel to 1). My attempts to clone the old setting for a recent version of NUT (2.8.0, backported from sid a few months ago) failed to start the set of drivers, so something must have changed while I wasn't looking. Is this approach still possible with NUT 2.8.x, and may I learn from someone who is running such a setup? Thanks in advance, Steffen -- Steffen Grunewald, Cluster Administrator Max Planck Institute for Gravitational Physics (Albert Einstein Institute) Am Mühlenberg 1 * D-14476 Potsdam-Golm * Germany ~~~ Fon: +49-331-567 7274 Mail: steffen.grunewald(at)aei.mpg.de ~~~ ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
