Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    NUT package (2.8.0 and below)

    Scheduled Pinned Locked Moved
    UPS Tools
    128
    1.2k
    3.0m
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • GertjanG
      Gertjan @kevindd992002
      last edited by

      @kevindd992002 said in NUT package:

      auto-updating not recommended

      Noop.
      The system might reboot to finish an update.
      And you were just about to shut down that nuclear power plant that reaching dangerous levels ...

      pfSense is not that solid that it can auto update and keep care of itself like, for example .. euh .... Windows 10 :)

      Put an "installed packages" widget on the dashboard, and visit the GUI ones in a while. That will do.
      Same thing for pfSense updates.

      Sorry for the out-of-subect.

      No "help me" PM's please. Use the forum, the community will thank you.
      Edit : and where are the logs ??

      K 1 Reply Last reply Reply Quote 0
      • K
        kevindd992002 @Gertjan
        last edited by

        @Gertjan said in NUT package:

        @kevindd992002 said in NUT package:

        auto-updating not recommended

        Noop.
        The system might reboot to finish an update.
        And you were just about to shut down that nuclear power plant that reaching dangerous levels ...

        pfSense is not that solid that it can auto update and keep care of itself like, for example .. euh .... Windows 10 :)

        Put an "installed packages" widget on the dashboard, and visit the GUI ones in a while. That will do.
        Same thing for pfSense updates.

        Sorry for the out-of-subect.

        Why didn't I think of that, lol! That's not a bad idea. Thanks!

        1 Reply Last reply Reply Quote 0
        • dennypageD
          dennypage @kevindd992002
          last edited by

          @kevindd992002 said in NUT package:

          1. It looks like I receive the message after reboot but not all the time. It happens randomly and it happens for both my pfsense boxes which have the same exact UPS, with the same exact pfsense version and set of settings.

          2. System logs around the time of the latest issue occurrence:

          May 5 17:48:01 	upsmon 	12113 	Startup successful
May 5 17:48:02 	usbhid-ups 	35012 	Startup successful
May 5 17:48:02 	upsd 	47110 	listening on 192.168.55.1 port 3493
May 5 17:48:02 	upsd 	47110 	listening on 192.168.10.1 port 3493
May 5 17:48:02 	upsd 	47110 	listening on ::1 port 3493
May 5 17:48:02 	upsd 	47110 	listening on 127.0.0.1 port 3493
May 5 17:48:02 	upsd 	47110 	Connected to UPS [ups]: usbhid-ups-ups
May 5 17:48:02 	upsd 	47942 	Startup successful
May 5 17:48:04 	upsmon 	43097 	Startup successful
May 5 17:48:05 	usbhid-ups 	72062 	Startup successful
May 5 17:48:05 	upsd 	10700 	listening on 192.168.55.1 port 3493
May 5 17:48:05 	upsd 	10700 	listening on 192.168.10.1 port 3493
May 5 17:48:05 	upsd 	10700 	listening on ::1 port 3493
May 5 17:48:05 	upsd 	10700 	listening on 127.0.0.1 port 3493
May 5 17:48:05 	upsd 	10700 	Connected to UPS [ups]: usbhid-ups-ups
May 5 17:48:05 	upsd 	12533 	Startup successful
May 5 17:48:06 	upsd 	12533 	User local-monitor@127.0.0.1 logged into UPS [ups]
May 5 17:48:06 	upsmon 	43843 	upsmon parent process died - shutdown impossible
May 5 17:48:06 	upsmon 	43843 	Parent died - shutdown impossible
May 5 17:48:06 	upsd 	12533 	mainloop: Interrupted system call
May 5 17:48:06 	upsd 	12533 	Signal 15: exiting
May 5 17:48:06 	usbhid-ups 	72062 	Signal 15: exiting
May 5 17:48:06 	upsmon 	77021 	Startup successful
May 5 17:48:07 	usbhid-ups 	9091 	Startup successful
May 5 17:48:07 	upsd 	19878 	listening on 192.168.55.1 port 3493
May 5 17:48:07 	upsd 	19878 	listening on 192.168.10.1 port 3493
May 5 17:48:07 	upsd 	19878 	listening on ::1 port 3493
May 5 17:48:07 	upsd 	19878 	listening on 127.0.0.1 port 3493
May 5 17:48:07 	upsd 	19878 	Connected to UPS [ups]: usbhid-ups-ups
May 5 17:48:07 	upsd 	21841 	Startup successful
May 5 17:48:09 	upsmon 	77021 	upsmon parent: read
May 5 17:48:09 	upsmon 	37716 	Startup successful
May 5 17:48:10 	usbhid-ups 	88380 	Startup successful
May 5 17:48:10 	upsd 	11383 	listening on 192.168.55.1 port 3493
May 5 17:48:10 	upsd 	11383 	listening on 192.168.10.1 port 3493
May 5 17:48:10 	upsd 	11383 	listening on ::1 port 3493
May 5 17:48:10 	upsd 	11383 	listening on 127.0.0.1 port 3493
May 5 17:48:10 	upsd 	11383 	Connected to UPS [ups]: usbhid-ups-ups
May 5 17:48:10 	upsd 	12532 	Startup successful
May 5 17:48:12 	upsd 	12532 	User local-monitor@::1 logged into UPS [ups]
May 5 17:48:13 	upsmon 	39038 	Signal 15: exiting
May 5 17:48:13 	upsd 	12532 	User local-monitor@::1 logged out from UPS [ups]
May 5 17:48:13 	upsd 	12532 	mainloop: Interrupted system call
May 5 17:48:13 	upsd 	12532 	Signal 15: exiting
May 5 17:48:13 	usbhid-ups 	88380 	Signal 15: exiting

          It looks like it shut itself down and then went back up.

          Ah... now I get it...

          There should be a bit more in the system log around that time. In particular, I would expect the following lines:

          /rc.start_packages: Starting service nut
/rc.start_packages: Restarting/Starting all packages.

          I expect that the packages are being restarted in response to a DHCP address event on one of your wan interfaces. This is normal and can be ignored. Sorry for causing you alarm.

          It's a bit unfortunate, but normal because pfSense does not know what packages require restart when an IP address changes, so it restarts them all. See /etc/rc.newwanip (and newwanipv6) for detail.

          K 1 Reply Last reply Reply Quote 0
          • K
            kevindd992002 @dennypage
            last edited by kevindd992002

            @dennypage said in NUT package:

            @kevindd992002 said in NUT package:

            1. It looks like I receive the message after reboot but not all the time. It happens randomly and it happens for both my pfsense boxes which have the same exact UPS, with the same exact pfsense version and set of settings.

            2. System logs around the time of the latest issue occurrence:

            May 5 17:48:01 	upsmon 	12113 	Startup successful
May 5 17:48:02 	usbhid-ups 	35012 	Startup successful
May 5 17:48:02 	upsd 	47110 	listening on 192.168.55.1 port 3493
May 5 17:48:02 	upsd 	47110 	listening on 192.168.10.1 port 3493
May 5 17:48:02 	upsd 	47110 	listening on ::1 port 3493
May 5 17:48:02 	upsd 	47110 	listening on 127.0.0.1 port 3493
May 5 17:48:02 	upsd 	47110 	Connected to UPS [ups]: usbhid-ups-ups
May 5 17:48:02 	upsd 	47942 	Startup successful
May 5 17:48:04 	upsmon 	43097 	Startup successful
May 5 17:48:05 	usbhid-ups 	72062 	Startup successful
May 5 17:48:05 	upsd 	10700 	listening on 192.168.55.1 port 3493
May 5 17:48:05 	upsd 	10700 	listening on 192.168.10.1 port 3493
May 5 17:48:05 	upsd 	10700 	listening on ::1 port 3493
May 5 17:48:05 	upsd 	10700 	listening on 127.0.0.1 port 3493
May 5 17:48:05 	upsd 	10700 	Connected to UPS [ups]: usbhid-ups-ups
May 5 17:48:05 	upsd 	12533 	Startup successful
May 5 17:48:06 	upsd 	12533 	User local-monitor@127.0.0.1 logged into UPS [ups]
May 5 17:48:06 	upsmon 	43843 	upsmon parent process died - shutdown impossible
May 5 17:48:06 	upsmon 	43843 	Parent died - shutdown impossible
May 5 17:48:06 	upsd 	12533 	mainloop: Interrupted system call
May 5 17:48:06 	upsd 	12533 	Signal 15: exiting
May 5 17:48:06 	usbhid-ups 	72062 	Signal 15: exiting
May 5 17:48:06 	upsmon 	77021 	Startup successful
May 5 17:48:07 	usbhid-ups 	9091 	Startup successful
May 5 17:48:07 	upsd 	19878 	listening on 192.168.55.1 port 3493
May 5 17:48:07 	upsd 	19878 	listening on 192.168.10.1 port 3493
May 5 17:48:07 	upsd 	19878 	listening on ::1 port 3493
May 5 17:48:07 	upsd 	19878 	listening on 127.0.0.1 port 3493
May 5 17:48:07 	upsd 	19878 	Connected to UPS [ups]: usbhid-ups-ups
May 5 17:48:07 	upsd 	21841 	Startup successful
May 5 17:48:09 	upsmon 	77021 	upsmon parent: read
May 5 17:48:09 	upsmon 	37716 	Startup successful
May 5 17:48:10 	usbhid-ups 	88380 	Startup successful
May 5 17:48:10 	upsd 	11383 	listening on 192.168.55.1 port 3493
May 5 17:48:10 	upsd 	11383 	listening on 192.168.10.1 port 3493
May 5 17:48:10 	upsd 	11383 	listening on ::1 port 3493
May 5 17:48:10 	upsd 	11383 	listening on 127.0.0.1 port 3493
May 5 17:48:10 	upsd 	11383 	Connected to UPS [ups]: usbhid-ups-ups
May 5 17:48:10 	upsd 	12532 	Startup successful
May 5 17:48:12 	upsd 	12532 	User local-monitor@::1 logged into UPS [ups]
May 5 17:48:13 	upsmon 	39038 	Signal 15: exiting
May 5 17:48:13 	upsd 	12532 	User local-monitor@::1 logged out from UPS [ups]
May 5 17:48:13 	upsd 	12532 	mainloop: Interrupted system call
May 5 17:48:13 	upsd 	12532 	Signal 15: exiting
May 5 17:48:13 	usbhid-ups 	88380 	Signal 15: exiting

            It looks like it shut itself down and then went back up.

            Ah... now I get it...

            There should be a bit more in the system log around that time. In particular, I would expect the following lines:

            /rc.start_packages: Starting service nut
/rc.start_packages: Restarting/Starting all packages.

            I expect that the packages are being restarted in response to a DHCP address event on one of your wan interfaces. This is normal and can be ignored. Sorry for causing you alarm.

            It's a bit unfortunate, but normal because pfSense does not know what packages require restart when an IP address changes, so it restarts them all. See /etc/rc.newwanip (and newwanipv6) for detail.

            Bingo!

            May 5 17:47:40 	php-fpm 	379 	/rc.start_packages: Starting service nut
May 5 17:48:01 	php-fpm 	379 	/rc.start_packages: Starting service nut
May 5 17:48:06 	php-fpm 	83711 	/rc.start_packages: Starting service nut
May 5 17:48:13 	php-fpm 	22562 	/rc.start_packages: Starting service nut
May 5 17:48:48 	php-fpm 	379 	/rc.start_packages: Starting service nut
May 7 17:33:27 	php-fpm 	379 	/rc.start_packages: Starting service nut 

            May 5 17:47:39 	php-fpm 	379 	/rc.start_packages: Restarting/Starting all packages.
May 5 17:48:00 	php-fpm 	379 	/rc.start_packages: Restarting/Starting all packages.
May 5 17:48:06 	php-fpm 	83711 	/rc.start_packages: Restarting/Starting all packages.
May 5 17:48:13 	php-fpm 	22562 	/rc.start_packages: Restarting/Starting all packages.
May 5 17:48:48 	php-fpm 	379 	/rc.start_packages: Restarting/Starting all packages.
May 7 17:33:27 	php-fpm 	379 	/rc.start_packages: Restarting/Starting all packages.

            The weird thing is that my WAN interface has a static IP. I have an OpenVPN interface though, does that count? Although I know that this error started happening even before configuring OpenVPN.

            dennypageD 2 Replies Last reply Reply Quote 0
            • K
              kevindd992002 @dennypage
              last edited by

              @dennypage said in NUT package:

              @kevindd992002 Slightly concerning is that it does not show any self test result...

              Batteries are generally rated for 3 years, so you may want to have a look at your battery health. You can initiate a battery test via nut, but you will have to use the command line. Log into the system and use

              upscmd -l ups

              to see what commands are available. Look for commands that begin "test.battery..." Start with a quick test if available, then proceed to a deep test.

              WARNING if the battery is defective, running these tests can cause the ups to cut power to the load (your pfSense box). Use at your own risk!

              Doing a quick test yielded a "done and passed" result for the last test result field. However, when I tried doing a deep test, the CLI returned an OK message but the UPS did nothing. Does that mean that the command is not supported by my UPS? I'm still receiving low battery message notifications in my email regarding this UPS.

              dennypageD 1 Reply Last reply Reply Quote 0
              • dennypageD
                dennypage @kevindd992002
                last edited by

                @kevindd992002 said in NUT package:

                The weird thing is that my WAN interface has a static IP. I have an OpenVPN interface though, does that count? Although I know that this error started happening even before configuring OpenVPN.

                Do you have IPv6 perhaps?

                K 1 Reply Last reply Reply Quote 0
                • dennypageD
                  dennypage @kevindd992002
                  last edited by

                  @kevindd992002 said in NUT package:

                  Doing a quick test yielded a "done and passed" result for the last test result field. However, when I tried doing a deep test, the CLI returned an OK message but the UPS did nothing. Does that mean that the command is not supported by my UPS? I'm still receiving low battery message notifications in my email regarding this UPS.

                  Have to try it with your other UPS, but my guess would be that the UPS is declining to initiate the deep test (which usually includes a battery calibration) because it has a low battery condition. Usually a deep test will not initiate on anything other than a completely full battery.

                  Best suggestion that I could make is to completely power off the UPS and restart it from the ground up. If that doesn't fix it, I would say that it's likely that the UPS or battery is defective.

                  K 1 Reply Last reply Reply Quote 0
                  • K
                    kevindd992002 @dennypage
                    last edited by

                    @dennypage

                    Nope, no IPv6. I made sure to disable it wherever I can.

                    1 Reply Last reply Reply Quote 0
                    • dennypageD
                      dennypage @kevindd992002
                      last edited by

                      @kevindd992002 I think rc.newwanip* can be invoked in several circumstances. Look in the system log for messages immediately preceding the Restarting/Starting all packages message.

                      K 1 Reply Last reply Reply Quote 0
                      • K
                        kevindd992002 @dennypage
                        last edited by kevindd992002

                        @dennypage said in NUT package:

                        @kevindd992002 I think rc.newwanip* can be invoked in several circumstances. Look in the system log for messages immediately preceding the Restarting/Starting all packages message.

                        May 10 13:08:43 	php-fpm 	14757 	/rc.newwanip: Resyncing OpenVPN instances for interface CCTV.
May 10 13:08:43 	php-fpm 	14757 	/rc.newwanip: Creating rrd update script
May 10 13:08:43 	upsd 	45275 	User local-monitor@::1 logged into UPS [ups]
May 10 13:08:43 	php-fpm 	378 	/rc.start_packages: Restarting/Starting all packages.
May 10 13:08:43 	radiusd 	48725 	Signalled to terminate
May 10 13:08:43 	radiusd 	48725 	Exiting normally
May 10 13:08:43 	php-fpm 	378 	/rc.start_packages: Stopping service nut
May 10 13:08:43 	upsmon 	72305 	Signal 15: exiting
May 10 13:08:43 	upsd 	45275 	User local-monitor@::1 logged out from UPS [ups]
May 10 13:08:43 	upsd 	45275 	mainloop: Interrupted system call
May 10 13:08:43 	upsd 	45275 	Signal 15: exiting
May 10 13:08:43 	usbhid-ups 	24821 	Signal 15: exiting
May 10 13:08:43 	php-fpm 	378 	/rc.start_packages: Starting service nut
May 10 13:08:43 	upsmon 	29518 	Startup successful
May 10 13:08:43 	php-fpm 	40655 	/rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 0.0.0.0 -> 192.168.40.1 - Restarting packages.
May 10 13:08:43 	check_reload_status 		Starting packages

                        You're right. What's the best approach to solve this though? It looks like even my OPT interfaces are interpreted as WANs. All my intefaces (WAN and LAN) have static IP's, so I'm not sure why there is an IP change event there.

                        dennypageD 1 Reply Last reply Reply Quote 0
                        • dennypageD
                          dennypage @kevindd992002
                          last edited by

                          @kevindd992002 I don't believe you can prevent this from occurring. Problem is, pfSense doesn't know what each package is doing with the various interfaces or if they support dynamic discovery of interface changes (most don't). The only way for pfSense to ensure everything is functioning correctly is to restart the packages.

                          K 1 Reply Last reply Reply Quote 0
                          • GertjanG
                            Gertjan
                            last edited by

                            I'm seeing this in my logs

                            php-fpm 	40655 	/rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 82.127.34.254 -> 82.127.34.254 - Restarting packages.

                            I was asling yself : what changed ? Why was this line triggered ?
                            For me, "82.127.34.254" is identical to "82.127.34.254".

                            My WAN is using an RFC 1918 IP (DHCP using an upstream router) - the real WAN IP - 82.127.34.254 - doesn't change, but still, packages get restarted.
                            For longtime I really thought this was completely unnecessary, nut now I knows that that processes like unbound or openvpn don't like the fact that an interface to which they are bound, go up and down, even when the IP on that interface stays the same.

                            No "help me" PM's please. Use the forum, the community will thank you.
                            Edit : and where are the logs ??

                            1 Reply Last reply Reply Quote 0
                            • K
                              kevindd992002 @dennypage
                              last edited by

                              @dennypage said in NUT package:

                              @kevindd992002 I don't believe you can prevent this from occurring. Problem is, pfSense doesn't know what each package is doing with the various interfaces or if they support dynamic discovery of interface changes (most don't). The only way for pfSense to ensure everything is functioning correctly is to restart the packages.

                              I see. Do you happen to know why the interface IP changes for no reason, in the first place?

                              dennypageD 1 Reply Last reply Reply Quote 0
                              • dennypageD
                                dennypage @kevindd992002
                                last edited by

                                @kevindd992002 In your case it looks like a change of state for OpenVPN interfaces. I'm sorry I don't know much beyond this. If you want to explore more, I'd suggest asking in the General pfSense Questions or OpenVPN groups.

                                K 2 Replies Last reply Reply Quote 0
                                • B
                                  bazzacad
                                  last edited by

                                  Can I use the 2 USB ports on my XG-7100 1U appliance to monitor my APC Smart-UPS 1500 with this package?

                                  dennypageD 1 Reply Last reply Reply Quote 0
                                  • dennypageD
                                    dennypage @bazzacad
                                    last edited by

                                    @bazzacad If the ups has a usb interface, I expect nut with the usbhid driver would work. You can always check the nut hardware compatibility matrix to confirm. Have you tried it and encountered a problem?

                                    B 1 Reply Last reply Reply Quote 0
                                    • K
                                      kevindd992002 @dennypage
                                      last edited by

                                      @dennypage said in NUT package:

                                      @kevindd992002 In your case it looks like a change of state for OpenVPN interfaces. I'm sorry I don't know much beyond this. If you want to explore more, I'd suggest asking in the General pfSense Questions or OpenVPN groups.

                                      Ok, thanks.

                                      I also have an error with my slave client but I'm not sure if it's OT here or not. Basically, my slave monitor client is a Debian box and it works just fine connecting to this pfsense master. But during boot time I get the same exact error described here. So what does the nut-driver.service do? Since the nut package here only runs as monitor (not server), do I need that service active?

                                      dennypageD 1 Reply Last reply Reply Quote 0
                                      • dennypageD
                                        dennypage @kevindd992002
                                        last edited by

                                        @kevindd992002 I'm an RC guy. I don't use systemd.

                                        That said, the link you posted is about a problem with usbhid-ups not being able to find the local ups on the serial bus. This is unrelated to use of upsmon to remotely monitor a ups.

                                        If you are seeing anything from upsdrvctl, it means that the system is misconfigured. In a remote monitor case, only upsmon would be started. The local services, upsdrvctl (usbhid-ups) and upsd are not used and should not be started.

                                        Please don't ask me how to configure systemd. I simply don't know. ☺

                                        K 1 Reply Last reply Reply Quote 0
                                        • K
                                          kevindd992002 @dennypage
                                          last edited by

                                          @dennypage said in NUT package:

                                          @kevindd992002 I'm an RC guy. I don't use systemd.

                                          That said, the link you posted is about a problem with usbhid-ups not being able to find the local ups on the serial bus. This is unrelated to use of upsmon to remotely monitor a ups.

                                          If you are seeing anything from upsdrvctl, it means that the system is misconfigured. In a remote monitor case, only upsmon would be started. The local services, upsdrvctl (usbhid-ups) and upsd are not used and should not be started.

                                          Please don't ask me how to configure systemd. I simply don't know. ☺

                                          Lol, ok. Yeah, that's what I figured. I'm only using the nut package their as a monitor so I don't think the other services should be started at all.

                                          1 Reply Last reply Reply Quote 0
                                          • B
                                            bazzacad @dennypage
                                            last edited by

                                            @dennypage Everything worked perfectly with my XG-7100 1U and APC Smart-UPS 1500 using the usbhid driver. Is the package able to monitor 2 UPSs? Both APC Smart-UPS 1500. I didn't try that yet?

                                            dennypageD 1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post