[SOLVED] Failed to start NUT-UPS service due to a system error

hi.

I have ippon smart power 1400.
Seems blazer_usb support it.

My settings are:
NUT Mode: standalone
NUT Driver : blazer_usb
UPS port: auto
NUT User: monuser
NUT Password: monpassword

After run I’ve got an error.
Failed to start NUT-UPS service due to a system error. Check the service is configured correctly via it’s spanner icon.

Oct 02 11:41:21 server systemd[1]: Reloading.
Oct 02 11:41:21 server systemd[1]: Configuration file /usr/lib/systemd/system/auditd.service is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway.
Oct 02 11:41:21 server systemd[1]: Configuration file /usr/lib/systemd/system/wpa_supplicant.service is marked executable. Please remove executable permission bits. Proceeding anyway.
Oct 02 11:41:21 server systemd[1]: Starting Network UPS Tools - power device driver controller...
-- Subject: Unit nut-driver.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit nut-driver.service has begun starting up.
Oct 02 11:41:21 server systemd-tmpfiles[11692]: Failed to open '/etc/tmpfiles.d/nut-run.conf', ignoring: No such file or directory
Oct 02 11:41:21 server upsdrvctl[11711]: Error: you must specify a port name in ups.conf. Try -h for help.
Oct 02 11:41:21 server upsdrvctl[11711]: Network UPS Tools - Megatec/Q1 protocol USB driver 0.11 (2.7.2)
Oct 02 11:41:21 server systemd[1]: nut-driver.service: control process exited, code=exited status=1
Oct 02 11:41:21 server upsdrvctl[11711]: Driver failed to start (exit status=1)
Oct 02 11:41:21 server upsdrvctl[11711]: Network UPS Tools - UPS driver controller 2.7.2
Oct 02 11:41:21 server systemd[1]: Failed to start Network UPS Tools - power device driver controller.
-- Subject: Unit nut-driver.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit nut-driver.service has failed.
--
-- The result is failed.
Oct 02 11:41:21 server systemd[1]: Dependency failed for Network UPS Tools - power devices information server.
-- Subject: Unit nut-server.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit nut-server.service has failed.
--
-- The result is dependency.
Oct 02 11:41:21 server systemd[1]: Job nut-server.service/start failed with result 'dependency'.
Oct 02 11:41:21 server systemd[1]: Unit nut-driver.service entered failed state.
Oct 02 11:41:21 server systemd[1]: nut-driver.service failed.

How can I fix it?

Error: you must specify a port name in ups.conf.

How to determine which usb port used by UPS?

[root@server ~]# lsusb
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 003 Device 002: ID 0781:5591 SanDisk Corp.
Bus 003 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 007: ID 0451:8044 Texas Instruments, Inc.
Bus 002 Device 003: ID 0cf3:3005 Atheros Communications, Inc. AR3011 Bluetooth
Bus 002 Device 005: ID 0665:5161 Cypress Semiconductor USB to Serial
Bus 001 Device 008: ID 0572:141a Conexant Systems (Rockwell), Inc.
Bus 001 Device 010: ID 0bda:58ba Realtek Semiconductor Corp.

@alexey Hello again.
With the usb drivers the auto is the correct setting but what I suspect has happened here is a miss interpretation of the auto setting, ie it is a suggestion/hint and I’m pretty sure it isn’t actually entered; see the mouse over note. Could you post in this thread a screen grab of your NUT configuration screen, ie the ‘spanner’ screen with the settings you posted earlier to see if this is the case?

You could then try filling in the port with auto, ie following the greyed out suggestion as that may get you up and running.

Hope that helps and if this turns our to be the issue then we can open a github issue to improve the user experience on this one by doing as the user and password fields do and make the suggestion more obviously not an actual setting.

You was right.

I’ve typed ‘auto’ into port input and now service is working. auto placeholder confuses :slight_smile:

What can I do with NUT next?
Can I set some rules or command on low battery level?

@alexey Glad it’s working for you and I agree this is confusing so I’ve opened an issue referencing this forum thread:


This way it’s ‘on record’ and ready for a pull request to sort.

Funny you should say that, we have an open issue assigned to myself that I am considering tending to fairly shortly as it’s marked for our next milestone so is pending my attention:

‘As is’ NUT defaults to shutting down the system when the UPS is both on battery (no mains) and when the battery is judged to be low; so essentially as long as the UPS can safely sustain the equipment. The above issue should make that arrangement a little more flexibly.

One thing you can do now is to enable email notifications (embeded link to official docs) as Rockstor’s NUT install defaults to sending changes of state emails to the root user on the system and with email notifications configured and enabled you would receive power state changes via email, along with communication errors with the UPS etc.

Another thing that may be useful is to change to netserver mode which would allow the UPS information to be shared with clients machines on the network so that they might also shutdown in the power compromised state; obviously this only makes sense if they and the network infrastructure are also powered by the same UPS. See the UPS / NUT Setup section of the official Rockstor documentation for your options. I also run a gnome extension detailed at the end of the Why NUT blog post to display UPS info and state on my desktop.

No rules or other commands I’m afraid, at least via the Web-UI. However you can use all the usual facilities of NUT via the command line and if you wish you could edit the /opt/rockstor/conf/upssched-cmd file to do more than just email on various events. Also if you wish to enable the popular feature of shutting down after a set period prior to the above issue being resolved then you can always unremark the last 2 lines in the /opt/rockstor/conf/upssched.conf and change their test values of 120 seconds to something more appropriate to your battery run time. Note however that any changes to these files will only take effect after re-submitting your existing or changed configuration via the Web-UI as they are the ‘template’ files used by Rockstor to write the active configuration.

Do take care if editing any of those system files though as you will have to observe log entries to know if your changes contain errors.

Hope that helps and I’ll try and get on with the referenced issue soon, especially given it’s current milestone status.

Thanks for so detailed answer :slight_smile:

Do you have any plans to create dashboard widget with UPS status?

@alexey

Funny you should say that also, yes this has been in mind from the start, see the “Future enhancements” section of the developers manual for the NUT subsystem:

But this is not currently on any milestone and does not yet exist as an official feature request. Though of course that could change (hint hint :slight_smile:). There are non obvious complexities involved in this such as not all UPS devices return the same set of data but this is not insurmountable.

Hope that helps.

@alexey Quick notification that as of testing channel updates version 3.8.15-3 both issues referenced in this thread:

and

have been resolved.