SLAVE UPS FIX

Do this at your own risk - requires root access, but the change is 100% reversible.

1. Create the following file as /etc/netdata/charts.d/nut_ups.conf - adjust MY_NUT_HOST to suit your own circumstances (this is your remote UPS IP address and/or port):

2. Restart netdata with systemctl restart netdata.service (or reboot).

3. That’s it. Steps #1 and #2 will need to be re-applied with each system upgrade (until an upstream fix arrives). ​

4. End result:

   1. Functioning Slave UPS monitoring

   2. Functioning Slave UPS graphs (local & remote)

   3. No netdata log spam

5. OPTIONAL: To automatically survive OS upgrades… add the following as a pre-init script (eg. /root/bin/post-upgrade):

where /root/bin/nut_ups.conf (line 10) is the location of the first script from #1 above.

I guess the golang collector will probably (hopefully) be able to connect to the remote upsd assuming netdata is suitably configured with the remote host address, which should then work. 🤞

I suppose it all depends what version of netdata will be used in Fangtooth.

If a version prior to 1.44 then there doesn’t appear to be a fix for the broken Slave mode. A temporary downstream solution/workaround as already proposed may be necessary to avoid the issues outlined above, until the switch to a golang-based version of netdata.

If 1.44 or later, then it’s all change to golang which may or may not work better with a remote UPS. 🤷‍♂️

I guess I’ll either try to fix this myself as a temporary/stop-gap solution, if only to stop the excessive log spam, or just go without UPS support entirely (which isn’t great on a NAS) because if you look at upstream, specifically netdata/netdata, it’s all changed from bash to golang (since v1.44) and the situation is now even worse as the new golang code has a hard dependency on upsd which won’t be available in Slave mode. 🤷‍♂️

So I’m not expecting this to be resolved upstream any time soon, if ever.

Hi William, unfortunately I don’t have access to the “other ticket” (presumably the other Jira issue linked in the GitHub PR?) so had no way of knowing why the GitHub PR with the proposed fix had been closed. Not sure if you’re aware of that access issue, or if it’s intentional?

And a minor improvement for the future - the “Init SSL without certificate database” whine emitted by upsc on stderr can now be disabled in NUT 2.8.1 thanks to the following PR - maybe that can be supported in the future netdata scripts if the upsc output to stderr is ever an issue (avoids redirection to /dev/null):

As mentioned in the other ticket, this needs to wait for the fix to be brought up in the version that we use from debian. Maybe it will be there for Fangtooth

This issue has now been closed. Comments made after this point may not be viewed by the TrueNAS Teams. Please open a new issue if you have found a problem or need to re-engage with the TrueNAS Engineering Teams.