upsdrvctl not auto-startup after reboot

[ketomagasaki]

Hello,

The hardware: Device: Raspberry Pi 4 Model B UPS: SMT1500I

I had installed a Raspberry Pi 4 and documented all the installation steps. I received a new Raspberry Pi 4 and performed the same installation, with the configuration command as follows:

./configure --with-openssl --with-user=root --with-group=root --with-usb --with-cgi --with-nut-scanner --with-modbus

Unfortunately, a new issue has arisen: The nut-server starts after a reboot, but not the driver. After a reboot, it says:

error: Driver not connected

And

If I execute upsdrvctl start, it works again. For automatic startup, I used this command: systemctl enable nut.target

If I execute 'systemctl status nut-server' after reboot, I get:

● nut-server.service - Network UPS Tools - power devices information server
     Loaded: loaded (/lib/systemd/system/nut-server.service; disabled; preset: enabled)
     Active: active (running) since Sun 2023-11-26 15:44:38 CET; 7min ago
    Process: 744 ExecStartPre=/usr/bin/systemd-tmpfiles --create /usr/lib/tmpfiles.d/nut-common-tmpfiles.conf (code=exited, status=0/SUCCESS)
   Main PID: 753 (upsd)
      Tasks: 1 (limit: 1578)
        CPU: 153ms
     CGroup: /system.slice/nut-server.service
             └─753 /usr/local/ups/sbin/upsd -F

Nov 26 15:44:38 rpy2 nut-server[753]: Running as foreground process, not saving a PID file
Nov 26 15:44:38 rpy2 upsd[753]: Running as foreground process, not saving a PID file
Nov 26 15:44:38 rpy2 nut-server[753]: /usr/local/ups/etc/certs/rpy2.locale.pem is world readable
Nov 26 15:44:38 rpy2 nut-server[753]: Warning: DISABLE_WEAK_SSL is not enabled. Please consider enabling to improve network security.
Nov 26 15:44:38 rpy2 upsd[753]: /usr/local/ups/etc/certs/rpy2.locale.pem is world readable
Nov 26 15:44:38 rpy2 upsd[753]: Warning: DISABLE_WEAK_SSL is not enabled. Please consider enabling to improve network security.
Nov 26 15:44:38 rpy2 nut-server[753]: upsnotify: failed to notify about state 2: no notification tech defined, will not spam more about it
Nov 26 15:44:38 rpy2 upsd[753]: upsnotify: failed to notify about state 2: no notification tech defined, will not spam more about it
Nov 26 15:49:38 rpy2 nut-server[753]: Can't connect to UPS [ups] (usbhid-ups-ups): No such file or directory
Nov 26 15:49:38 rpy2 upsd[753]: Can't connect to UPS [ups] (usbhid-ups-ups): No such file or directory

It adds '-ups' to the driver :O

I don't really understand the behavior, whereas if I execute 'upsdrvctl start', it works correctly again.

Did I forget something?

[jimklimov]

Does it start any of the services named like nut-driver-enumerator? (Also you can run its script once you define a device in ups.conf) - it should set up a systemd unit instance like nut-driver@ups.service for each driver,

[jimklimov]

Also, can you share the ups.conf contents?

The question on naming (usbhid-ups-ups) can be answered by the pipe-file pattern being ${DRIVER}-${DEVICENAME} -- so assuming your ups.conf section for the device is named [ups] and includes a driver="usbhid-ups" line.

I saw that your configure line includes a --with-modbus which may be useful given the (APC?) SMT1500I you use. Note that per #2063 you would at this time need a custom-built libmodbus with support for USB compiled and installed first, and then build NUT as its consumer so the apc_modbus driver would work with not only Serial and TCP media, but also USB.

[ketomagasaki]

Does it start any of the services named like nut-driver-enumerator? (Also you can run its script once you define a device in ups.conf) - it should set up a systemd unit instance like nut-driver@ups.service for each driver,

I restarted the Raspberry Pi and checked systemctl status nut-driver-enumerator:

○ nut-driver-enumerator.service - Network UPS Tools - enumeration of configure-file devices into systemd unit instances
Loaded: loaded (/lib/systemd/system/nut-driver-enumerator.service; disabled; preset: enabled)
Active: inactive (dead)

journalctl | grep -E "nut-driver-enumerator" doesn't provide any logs for today. I don't think it's running. journalctl | grep -E "nut-driver" only shows stop logs before the reboot.

Also, can you share the ups.conf contents?

The question on naming (usbhid-ups-ups) can be answered by the pipe-file pattern being ${DRIVER}-${DEVICENAME} -- so assuming your ups.conf section for the device is named [ups] and includes a driver="usbhid-ups" line.

I saw that your configure line includes a --with-modbus which may be useful given the (APC?) SMT1500I you use. Note that per #2063 you would at this time need a custom-built libmodbus with support for USB compiled and installed first, and then build NUT as its consumer so the apc_modbus driver would work with not only Serial and TCP media, but also USB.

Here is my configuration of ups.conf:

pollinterval = 1
maxretry = 3
[ups]
    driver = usbhid-ups
    port = auto
    desc = "Secondary APC"

Yes, I am using an APC. I performed tests #2162 with the rack model, and the conclusion was that I needed to use Modbus with the usbhid-ups driver via USB. Therefore, I am attempting to do the same thing with the APC in tower model. I have not yet received the communication card, but the initial tests are working (after manual startup).

[jimklimov]

Just to be clear on terminology: Modbus is a protocol (which can be sent over Serial, USB, TCP... links); HID is also a protocol (typically assumes USB HID, although MGE also had "SHUT" aka "Serial HID UPS Transfer"). So these are two languages that your device might talk with different proficiency, and different NUT drivers as counterparts. APC may have some more protocols implemented on this or that device or add-on card, necessitating further drivers we have.

So if you want to give a try to Modbus over USB, you must follow that linked PR's description to build the custom libmodbus and a custom NUT using it (for the latter, you can check the Wiki article on "in-place" builds so the custom NUT would be configured as similarly as possible to the installed package and can act as its replacement if you are satisfied with testing from the build area).

The service "screenshot" above says it is disabled, may be a packaging/presets problem which is currently outside of NUT (it does not ship a reference systemd-presets template... although maybe it should...) Confusingly, it also says preset: enabled so not sure why it was not turned on. Reports from other users of NUT v2.8.0 and v2.8.1 indicated that their nut-driver@upsname units did appear, sometimes to their surprise, so perhaps it is different OSes using variations derived from the common Debian-first package?.. Really can't elaborate more beyond pure imagination here.

It is also possible that this system activated some other service, there are a few use-cases implemented by NDE. Can you check systemctl -a | grep nut-driver-enumerator to see if any such service is active (may be also "dead" if it is a one-shot variant that ran and finished).

Anyhow, you have a chance to either systemctl enable nut-driver-enumerator.{service,path} to have it run automatically at startup and whenever you edit and save /etc/nut/ups.conf, or to find where the packaging placed nut-driver-enumerator.sh and run it directly at your discretion (after editing the configuration, if you would do so after success of initial setup) to redefine the systemd unit to match any significant changes.