NUT package (2.8.0 and below)

dennypage

@kevindd992002 said in NUT package:

In the past, you mentioned that the override.battery.charge.low and override.battery.runtime.low parameters are added in the Extra Arguments to driver section and that's what I've been doing since the very start. But in the NUT documentation, it says there to put it in the Additional configuration for ups.conf section. So which is which and what is the difference?

From the ups.conf man page: “The file begins with global directives, and then each UPS has a section which contains a number of directives that set parameters for that UPS.”

The battery variable overrides are not global directives. They are fields in a ups definition.

kevindd992002

@dennypage said in NUT package:

@kevindd992002 said in NUT package:

In the past, you mentioned that the override.battery.charge.low and override.battery.runtime.low parameters are added in the Extra Arguments to driver section and that's what I've been doing since the very start. But in the NUT documentation, it says there to put it in the Additional configuration for ups.conf section. So which is which and what is the difference?

From the ups.conf man page: “The file begins with global directives, and then each UPS has a section which contains a number of directives that set parameters for that UPS.”

The battery variable overrides are not global directives. They are fields in a ups definition.

Right. But then those fields in a ups definition are still located in the ups.conf file, right? I'm still confused. In the ups.conf file, the override variable is listed under UPS fields which are under ups.conf.

dennypage

@kevindd992002 Yes, they are in the same file. ups.conf looks like this:

Global directive 1
Global directive 2
[ups1]
Field 1 = X
Field 2 = X
[ups2]
Field 1 = X
Field 2 = X

kevindd992002

@dennypage said in NUT package:

@kevindd992002 Yes, they are in the same file. ups.conf looks like this:

Global directive 1
Global directive 2
[ups1]
Field 1 = X
Field 2 = X
[ups2]
Field 1 = X
Field 2 = X

Ok, so if I understand this correctly:

Anytime you add something in the "Extra arguments" section in the pfsense NUT GUI, you effectively add those under the ups definition fields in ups.conf file.
Anytime you add asomething in the "ups.conf" section in the pfsense NUT GUI, you effectively add those as Global directives under the same ups.conf file.

Do those sound about right?

dennypage

@kevindd992002

Yes. Isn't this clear from the help text for both sections?

kevindd992002

@dennypage said in NUT package:

@kevindd992002

Yes. Isn't this clear from the help text for both sections?

I read the help text for the ups.conf field and it is clear now to me. But for the Extra arguments to the NUT driver, it doesn't say that those will go to the ups.conf file too, so I got confused.

kevindd992002

@dennypage , do you have any comments regarding my USB issues?

dennypage

@kevindd992002 You didn’t post usb entries from the system log. You need both the UPS and USB entries from the system log for the times in question.

What I’m expecting to see in there is that the USB connection is lost which is what triggers NUT’s loss of connection. This would indicate that the issue isn’t associated with NUT at all. See earlier in this thread for several discussions of USB driver issues.

kevindd992002

@dennypage said in NUT package:

@kevindd992002 You didn’t post usb entries from the system log. You need both the UPS and USB entries from the system log for the times in question.

What I’m expecting to see in there is that the USB connection is lost which is what triggers NUT’s loss of connection. This would indicate that the issue isn’t associated with NUT at all. See earlier in this thread for several discussions of USB driver issues.

Sorry, I had a typo in my previous post above. Those were the last 1000 "usb" logs (not ups logs) in the system log. I just filtered the system logs by message="ups". Did you want something else?

dennypage

@kevindd992002 What I was looking for, it was all logs containing "usb" or "ups". For instance the logs above contain only items matching "usb" which means things like "upsmon" will not be present.

However in looking at the ups logs immediately above, I don't actually see any disconnects. Did I misunderstand what your problem is? I tried going back through your posts in the thread, but they go back over a year so I may be confused as to what is current.

Can you restate what your current problem is please? Thanks.

kevindd992002

@dennypage said in NUT package:

@kevindd992002 What I was looking for, it was all logs containing "usb" or "ups". For instance the logs above contain only items matching "usb" which means things like "upsmon" will not be present.

However in looking at the ups logs immediately above, I don't actually see any disconnects. Did I misunderstand what your problem is? I tried going back through your posts in the thread, but they go back over a year so I may be confused as to what is current.

Can you restate what your current problem is please? Thanks.

The current problem are the USB disconnects in these posts:

https://forum.netgate.com/post/876424 -> these logs are filtered by message="ups", so upsmon logs are there
https://forum.netgate.com/post/876681 -> these logs are filtered by message="usb"

I'm seeing these logs:

upsmon parent process died
Communications with UPS ups lost
Can't connect to UPS [ups] (usbhid-ups-ups): No such file or directory
Can't connect to UPS [ups] (usbhid-ups-ups): Connection refused

dennypage

@kevindd992002 Are these happening at start up? Or are they happening sporadically?

kevindd992002

@dennypage These happen intermittently. As an example, here are the ups and usb logs for today when there was no power interruption of any kind:

ups logs:

Nov 27 13:38:48	upsd	41381	User local-monitor@::1 logged into UPS [ups]
Nov 27 13:38:47	upsd	41381	User monuser@192.168.10.10 logged into UPS [ups]
Nov 27 13:38:47	upsd	41381	Connected to UPS [ups]: usbhid-ups-ups
Nov 27 13:38:46	upsd	41166	Can't connect to UPS [ups] (usbhid-ups-ups): Connection refused
Nov 27 13:38:43	upsd	37228	Can't connect to UPS [ups] (usbhid-ups-ups): Connection refused
Nov 27 13:38:42	upsd	57752	User local-monitor@::1 logged out from UPS [ups]
Nov 27 13:38:07	upsd	57752	User monuser@192.168.10.10 logged into UPS [ups]
Nov 27 13:38:03	upsd	57752	User local-monitor@::1 logged into UPS [ups]
Nov 27 13:38:03	upsd	57752	Connected to UPS [ups]: usbhid-ups-ups
Nov 27 13:38:01	upsd	57439	Can't connect to UPS [ups] (usbhid-ups-ups): Connection refused
Nov 27 13:37:58	upsd	53471	Can't connect to UPS [ups] (usbhid-ups-ups): No such file or directory
Nov 27 13:37:57	upsd	12981	User local-monitor@::1 logged out from UPS [ups]

usb logs:

Nov 27 13:38:47	upsd	41381	Connected to UPS [ups]: usbhid-ups-ups
Nov 27 13:38:46	upsd	41166	Can't connect to UPS [ups] (usbhid-ups-ups): Connection refused
Nov 27 13:38:43	upsd	37228	Can't connect to UPS [ups] (usbhid-ups-ups): Connection refused
Nov 27 13:38:03	upsd	57752	Connected to UPS [ups]: usbhid-ups-ups
Nov 27 13:38:01	upsd	57439	Can't connect to UPS [ups] (usbhid-ups-ups): Connection refused
Nov 27 13:37:58	upsd	53471	Can't connect to UPS [ups] (usbhid-ups-ups): No such file or directory

kevindd992002

@dennypage

I tested my new UPS again and had these results:

If you check under UPS details, my battery.charge.low is set to 60% and battery.runtime.low is set to 396s. I unplugged the UPS from the wall outlet to recreate a blackout and I was expecting NUT to issue an FSD when either charge.low or runtime.low is reached, whichever comes first. But if you check the UPS Status, the actual charge is at 47% already and the runtime at 300s, yet I'm not still seeing it sending an FSD to the slaves.

The FSD was sent until the UPS' built-in "low battery" meter is reached and my Synology was notified to shutdown. Why is this?

dennypage

@kevindd992002 said in NUT package:

@dennypage These happen intermittently. As an example, here are the ups and usb logs for today when there was no power interruption of any kind:

Can't give you much guidance without the corresponding system logs. USB bus disconnects, WAN link changes, DHCP events, etc. can all cause a restart of NUT. You need to look at the entire system state of the system at the time of the event.

dennypage

@kevindd992002 Did you have ignorelb set?

kevindd992002

@dennypage no I didn't. Is it required so that the overrides will work? I thought otherwise.

kevindd992002

@dennypage said in NUT package:

@kevindd992002 said in NUT package:

@dennypage These happen intermittently. As an example, here are the ups and usb logs for today when there was no power interruption of any kind:

Can't give you much guidance without the corresponding system logs. USB bus disconnects, WAN link changes, DHCP events, etc. can all cause a restart of NUT. You need to look at the entire system state of the system at the time of the event.

Would you want a copy of all system logs at that time frame? I'm not sure what to check specifically because I have two pfsense boxes with roughly the same settings but I only encounter it with one box that has the APC SUA750.

dennypage

@kevindd992002 said in NUT package:

@dennypage no I didn't. Is it required so that the overrides will work? I thought otherwise.

Yes. The description in the ignorelb section of the ups.conf man page tries to say this.

While the description in the documentation is somewhat vague, the code in drivers/dstate.c makes it clear:

void status_commit(void)
{
    while (ignorelb) {
        const char  *val, *low;

        val = dstate_getinfo("battery.charge");
        low = dstate_getinfo("battery.charge.low");

        if (val && low && (strtol(val, NULL, 10) < strtol(low, NULL, 10))) {
            snprintfcat(status_buf, sizeof(status_buf), " LB");
            upsdebugx(2, "%s: appending LB flag [charge '%s' below '%s']", __func__, val, low);
            break;
        }

        val = dstate_getinfo("battery.runtime");
        low = dstate_getinfo("battery.runtime.low");

        if (val && low && (strtol(val, NULL, 10) < strtol(low, NULL, 10))) {
            snprintfcat(status_buf, sizeof(status_buf), " LB");
            upsdebugx(2, "%s: appending LB flag [runtime '%s' below '%s']", __func__, val, low);
            break;
        }

        /* LB condition not detected */
        break;
    }

    if (alarm_active) {
        dstate_setinfo("ups.status", "ALARM %s", status_buf);
    } else {
        dstate_setinfo("ups.status", "%s", status_buf);
    }
}

battery.charge.low and battery.runtime.low are not used unless ignorelb is set. Probably not how I would have done it, but I don't own the code.

dennypage

@kevindd992002 Look at the system logs for the minute preceding the event. See what's going on. You should be able to identify a trigger. If you aren't having USB disconnects, then it's likely something like an interface flap or DHCP renewal.