NUT package (2.8.0 and below)
-
@sir_ssv said in NUT package:
What a coincidence. I haven’t upgraded to 2.5.0 (still on 2.4.5) and the other night I rebooted pfSense and the nut Daemon was reporting the same error.
My NUT driver suddenly started reporting the error about 24 hours ago. Still on 2.4.5 and hadn't rebooted, upgraded or changed anything in pfSense. Running through SNMP on a Cyberpower RMCARD203.
@duruser said in NUT package:
I think you have to set the branch manually to 2.4.5.
I reset the branch manually and reinstalled NUT which has appeared to have fixed the issue.
Not sure why things just stopped working.
-
@kesawi said in NUT package:
Not sure why things just stopped working.
Strange. You didn't update or install any new package since February 15th?
FWIW, the core reason this happens is because the latest stable repo doesn't have a version number in the name. When a new stable is released, it overwrites the prior repo configuration. When you explicitly set the branch, it uses the repo that specifically matches that version.
You can see the current repo in <pkg_repo_conf_path> in the config file. Your system likely has three repos to choose from:
- pfSense-repo-245.conf (2.4.5 repo)
- pfSense-repo-devel.conf (current stable repo)
- pfSense-repo.conf (dev snapshot repo)
pfSense-repo-245.conf was pfSense-repo.conf until 2.5.0 was released.
-
@dennypage Is this why NUT has suddenly stopped working on my 2.4.5 release?
What exactly do I need to do to resolve this issue? I've already stopped and started the service. I haven't uninstalled and reinstalled the NUT application as I was going to upgrade to 2.5.0 but have read of some issues. So, will sit on the side lines until another release is out.
Everything was working just great since my 2.4.5 install which covers more than nine months if not longer. Now all of the sudden it's broken out of no where?!?
-
@teken If you wanting to stay on 2.4.5, you need to explicitly set the branch in System -> Update to "Previous stable version (2.4.5 DEPRECATED)". Following that, re-install the NUT package via System -> Package Manager.
-
@dennypage If it hasn't been stated today your continued support and insight in the forums with respect to NUT is greatly appreciated!
Followed your steps and had to reboot a couple of times for the system to allow me to install NUT.
Your Rock & Know It . . .
Thank You ~ Sir!
-
@dennypage said in NUT package:
Strange. You didn't update or install any new package since February 15th?
No I haven't done either of those. The only thing that changed in my pfSense configuration was adding two extra dynamic DNS providers last week. The errors just started suddenly yesterday with no changes made.
-
@teken Very kind of you to say. Thank you.
-
wow, I just checked my pfsense setup and all traces of the nut package are gone. Bet this happened with the 2.5 branch snafu. great.
-
@duruser Prior to following @dennypage I had the NUT service stopped. Upon completing the steps as outlined above I found that NUT was missing?!?
As noted up above the solution was to reboot twice and reinstall NUT again. One thing I was surprised to see is locking the system to Previous Stable actually made the system download and install 2.4.5 P1?!?
I understand the reasons for P1 but the system should have just installed EXACTLY what was on the machine prior to this crazy auto snafu!
Regardless, I'm back in action and must again state much thanks to @dennypage!
-
@teken
Same here. Nut was no longer installed. I had to re-install the package from package manager and reboot. Luckily all the settings were still there. All working good now. -
I'm trying to troubleshoot why my Synology NAS (as a NUT client) is always giving me an improper shutdown message when power comes back in our area. Here are the logs on my pfsense box:
Jul 17 06:09:38 shutdown 24254 power-down by root: Jul 17 06:09:36 upsd 18585 User monuser@192.168.10.10 logged into UPS [ups] Jul 17 06:09:33 upsmon 83642 Auto logout and shutdown proceeding Jul 17 06:09:33 upsmon 83642 Executing automatic power-fail shutdown Jul 17 06:09:33 upsd 18585 User monuser@192.168.10.10 logged out from UPS [ups] Jul 17 06:08:24 php 53870 nut_email.php: Message sent to kevindd992002@yahoo.com OK Jul 17 06:08:13 upsd 18585 Client local-monitor@::1 set FSD on UPS [ups] Jul 17 06:08:13 upsmon 83642 UPS ups battery is low Jul 17 06:04:15 php 36392 nut_email.php: Message sent to kevindd992002@yahoo.com OK Jul 17 06:04:02 upsmon 83642 UPS ups on batteryI have the settings in the NUT server:
So at 6:08:13, the NUT server set an FSD signal to its clients. From what I understand from our past discussions, HOSTSYNC 300 will make the NUT server wait for 5 minutes before it actually shuts down itself. If that's the case, why do the logs say that the shutdown process started at 6:09:33? That's a mere 1 minute 20 seconds from the time it sent an FSD and I don't think this is enough time for the Synology to initiate that shutdown sequence.
-
@kevindd992002 said in NUT package:
So at 6:08:13, the NUT server set an FSD signal to its clients. From what I understand from our past discussions, HOSTSYNC 300 will make the NUT server wait for 5 minutes before it actually shuts down itself. If that's the case, why do the logs say that the shutdown process started at 6:09:33? That's a mere 1 minute 20 seconds from the time it sent an FSD and I don't think this is enough time for the Synology to initiate that shutdown sequence.
HOSTSYNC is the longest time that NUT will wait for all remote monitors to gracefully disconnect before continuing the shutdown sequence. The logs show a remote logging out:
Jul 17 06:09:33 upsd 18585 User monuser@192.168.10.10 logged out from UPS [ups]Once the last remote monitor has logged out, NUT is free to continue the local shutdown sequence. This sequence ends with a command to the UPS to turn off the load. The UPS does this after a short, and usually configurable, delay.
The issue is that the Synology is taking too long from the point that it shuts down NUT to the point that it actually powers off. To address this, you need to lengthen the amount of time the UPS delays before turning off the load. How to do this varies with UPS models and driver. If it is directly configurable via NUT, it will be variable "ups.delay.shutdown" (see upsc and upsrw doc).
If it is not directly configurable via NUT, consult your UPS documentation for info on how to configure the delay.
-
@dennypage said in NUT package:
@kevindd992002 said in NUT package:
So at 6:08:13, the NUT server set an FSD signal to its clients. From what I understand from our past discussions, HOSTSYNC 300 will make the NUT server wait for 5 minutes before it actually shuts down itself. If that's the case, why do the logs say that the shutdown process started at 6:09:33? That's a mere 1 minute 20 seconds from the time it sent an FSD and I don't think this is enough time for the Synology to initiate that shutdown sequence.
HOSTSYNC is the longest time that NUT will wait for all remote monitors to gracefully disconnect before continuing the shutdown sequence. The logs show a remote logging out:
Jul 17 06:09:33 upsd 18585 User monuser@192.168.10.10 logged out from UPS [ups]Once the last remote monitor has logged out, NUT is free to continue the local shutdown sequence. This sequence ends with a command to the UPS to turn off the load. The UPS does this after a short, and usually configurable, delay.
The issue is that the Synology is taking too long from the point that it shuts down NUT to the point that it actually powers off. To address this, you need to lengthen the amount of time the UPS delays before turning off the load. How to do this varies with UPS models and driver. If it is directly configurable via NUT, it will be variable "ups.delay.shutdown" (see upsc and upsrw doc).
If it is not directly configurable via NUT, consult your UPS documentation for info on how to configure the delay.
I see, what you're saying. I guess I had a partial understanding of HOSTSYNC. How does the NUT server know which remote monitors to wait for before it actually considers all remote monitors already logged out? Does it have some kind of a table?
Also, at what point exactly do remote monitors (Synology in this case) gracefully disconnect from the NUT server? Is it right after the successfully receive the FSD from the NUT server and initiate their shutdown sequences?
As for "ups.delay.shutdown", I just checked and yes the NUT GUI in pfsense does show that ups.delay.shutdown = 20 for both my Eaton and APC UPS'es, so I should be able to configure it to a longer delay.
-
@kevindd992002 said in NUT package:
How does the NUT server know which remote monitors to wait for before it actually considers all remote monitors already logged out? Does it have some kind of a table?
Each NUT monitor has a TCP connection to the server. When the monitor "logs out" it closes its TCP connection.
Also, at what point exactly do remote monitors (Synology in this case) gracefully disconnect from the NUT server?
Implementation dependent. Usually receipt of the FSD causes the standard system shutdown sequence to begin, which terminates various processes including the NUT monitor process. The order in which the shutdown sequence stops processes is outside of NUT's control.
As for "ups.delay.shutdown", I just checked and yes the NUT GUI in pfsense does show that ups.delay.shutdown = 20 for both my Eaton and APC UPS'es, so I should be able to configure it to a longer delay.
Note that the delay isn't something you set in the pfSense NUT config. You will need to use upsrw to update the delay setting in the UPS itself.
-
@dennypage said in NUT package:
@kevindd992002 said in NUT package:
How does the NUT server know which remote monitors to wait for before it actually considers all remote monitors already logged out? Does it have some kind of a table?
Each NUT monitor has a TCP connection to the server. When the monitor "logs out" it closes its TCP connection.
Also, at what point exactly do remote monitors (Synology in this case) gracefully disconnect from the NUT server?
Implementation dependent. Usually receipt of the FSD causes the standard system shutdown sequence to begin, which terminates various processes including the NUT monitor process. The order in which the shutdown sequence stops processes is outside of NUT's control.
As for "ups.delay.shutdown", I just checked and yes the NUT GUI in pfsense does show that ups.delay.shutdown = 20 for both my Eaton and APC UPS'es, so I should be able to configure it to a longer delay.
Note that the delay isn't something you set in the pfSense NUT config. You will need to use upsrw to update the delay setting in the UPS itself.
So as long as there are no more TCP connections to the NUT server, the server can freely start tye local shutdown sequence, got it.
Ok, I'll check out the delay. Do you have good increased value recommendation to start with?
-
@kevindd992002 said in NUT package:
Ok, I'll check out the delay. Do you have good increased value recommendation to start with?
Start a shutdown on the Synology and check the amount of time between the log off message in pfSense and the time the Synology actually powers off.
I’ve seen a lot of variation in shutdown time on the Synology depending upon what’s running (packages, docker containers, VMs). FWIW, DSM 7 seems to speed things up a bit.
-
@dennypage said in NUT package:
@kevindd992002 said in NUT package:
Ok, I'll check out the delay. Do you have good increased value recommendation to start with?
Start a shutdown on the Synology and check the amount of time between the log off message in pfSense and the time the Synology actually powers off.
I’ve seen a lot of variation in shutdown time on the Synology depending upon what’s running (packages, docker containers, VMs). FWIW, DSM 7 seems to speed things up a bit.
I see. But manually shutting down a Synology is not the same as it doing a "safe shutdown". A safe shutdown happens when an FSD is received and it doesn't actually power off the NAS but only dismounts the drives and turns off the services IIRC. As for the time difference between these two events, I'm not sure. I don't know how to accurately time a safe shutdown because the lights in the NAS are physically on when it happens.
-
@kevindd992002 There's no magic in NUT. A NUT "safe shutdown" is usually invoking a standard system command. For example, "/bin/shutdown -p +0" is used on pfSense.
I've recently upgraded from DSM6 to DSM7. I don't have a DSM6 system to examine, and I haven't had an opportunity to look at NUT in DSM7 to see how it is configured.
-
@dennypage said in NUT package:
@kevindd992002 There's no magic in NUT. A NUT "safe shutdown" is usually invoking a standard system command. For example, "/bin/shutdown -p +0" is used on pfSense.
I've recently upgraded from DSM6 to DSM7. I don't have a DSM6 system to examine, and I haven't had an opportunity to look at NUT in DSM7 to see how it is configured.
That's not entirely true. Have you recently noticed how a Synology NAS acts when it receives an FSD from the NUT server? It only does a safe shutdown, not a complete shutdown. I'm a 100% sure of this as I've been working in the past with Synology support regarding this. I didn't understand why it wasn't turning off completely so I thought I asked them. They said that it is by design that when you set a Synology NAS to shutdown with the "same as server" option, it only does a safe shutdown. It dismounts the drives and kills the services. When that process happens and power is cutoff by the UPS, then it's the same effect as a graceful/complete shutdown. I can vouch for this in DSM 6. I recently upgraded to DSM 7 but I'm not sure if it'll still work that way.
-
I think they're also calling it safe mode instead of shutdown. See post of Ramzi in this thread:
https://community.synology.com/enu/forum/1/post/121370?page=2&sort=oldest
In short, when Synology receives an FSD signal, it goes to safe mode. It does not shut down at all. It only gets turned off when the UPS cuts off power to it.
