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

    Check_reload_status: Reloading filter - Constantly reloading

    General pfSense Questions
    5
    8
    4.1k
    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.
    • W
      wwwparker
      last edited by

      I have a fresh installation of 2.1 with the following packages:

      Snort - 2.9.4.6 pkg v. 2.6.0
      PfBlocker - 1.0.2

      No dyndns, IPSEC, OpenVPN, or other settings have been configured.  This is a stock 2.1 installation with snort and pfblocker installed.

      A sample of my system logs:

      Oct 19 10:44:26 check_reload_status: Reloading filter
      Oct 19 10:44:26 check_reload_status: Restarting OpenVPN tunnels/interfaces
      Oct 19 10:44:26 check_reload_status: Restarting ipsec tunnels
      Oct 19 10:44:26 check_reload_status: updating dyndns WAN_DHCP
      Oct 19 10:40:07 check_reload_status: Reloading filter
      Oct 19 10:40:07 check_reload_status: Restarting OpenVPN tunnels/interfaces
      Oct 19 10:40:07 check_reload_status: Restarting ipsec tunnels
      Oct 19 10:40:07 check_reload_status: updating dyndns WAN_DHCP
      Oct 19 10:39:18 check_reload_status: Reloading filter
      Oct 19 10:39:18 check_reload_status: Restarting OpenVPN tunnels/interfaces
      Oct 19 10:39:18 check_reload_status: Restarting ipsec tunnels
      Oct 19 10:39:18 check_reload_status: updating dyndns WAN_DHCP
      Oct 19 10:37:44 check_reload_status: Reloading filter
      Oct 19 10:37:44 check_reload_status: Restarting OpenVPN tunnels/interfaces
      Oct 19 10:37:44 check_reload_status: Restarting ipsec tunnels
      Oct 19 10:37:44 check_reload_status: updating dyndns WAN_DHCP
      Oct 19 10:37:32 check_reload_status: Reloading filter
      Oct 19 10:37:32 check_reload_status: Restarting OpenVPN tunnels/interfaces
      Oct 19 10:37:32 check_reload_status: Restarting ipsec tunnels
      Oct 19 10:37:32 check_reload_status: updating dyndns WAN_DHCP
      Oct 19 10:36:34 php: /index.php: Successful login for user 'xxxxx' from: xx.xx.xx.xx
      Oct 19 10:36:34 php: /index.php: Successful login for user 'xxxxx' from: xx.xx.xx.xx
      Oct 19 10:34:41 check_reload_status: Reloading filter
      Oct 19 10:34:41 check_reload_status: Restarting OpenVPN tunnels/interfaces
      Oct 19 10:34:41 check_reload_status: Restarting ipsec tunnels
      Oct 19 10:34:41 check_reload_status: updating dyndns WAN_DHCP
      Oct 19 10:33:45 check_reload_status: Reloading filter
      Oct 19 10:33:45 check_reload_status: Restarting OpenVPN tunnels/interfaces
      Oct 19 10:33:45 check_reload_status: Restarting ipsec tunnels
      Oct 19 10:33:45 check_reload_status: updating dyndns WAN_DHCP
      Oct 19 10:33:25 check_reload_status: Reloading filter
      Oct 19 10:33:25 check_reload_status: Restarting OpenVPN tunnels/interfaces
      Oct 19 10:33:25 check_reload_status: Restarting ipsec tunnels
      Oct 19 10:33:25 check_reload_status: updating dyndns WAN_DHCP
      Oct 19 10:33:13 check_reload_status: Reloading filter
      Oct 19 10:33:13 check_reload_status: Restarting OpenVPN tunnels/interfaces
      Oct 19 10:33:13 check_reload_status: Restarting ipsec tunnels
      Oct 19 10:33:13 check_reload_status: updating dyndns WAN_DHCP
      Oct 19 10:32:58 check_reload_status: Reloading filter
      Oct 19 10:32:58 check_reload_status: Restarting OpenVPN tunnels/interfaces
      Oct 19 10:32:58 check_reload_status: Restarting ipsec tunnels
      Oct 19 10:32:58 check_reload_status: updating dyndns WAN_DHCP
      Oct 19 10:32:46 check_reload_status: Reloading filter

      For the sake of brevity this small sample should suffice - it goes on like this for the last 24 hours - I cannot determine a "trigger" for this behavior.  Having searched the backlogs for this specific issue I haven't found a solution.  (http://forum.pfsense.org/index.php?topic=56884.0) Some have reported similar issues with apinger and the time set for the gateway probe interval and the down time alarm threshold.  I've left these at their default values of 1 and 10 respectively, relaxed them a tad (3 seconds, 30 seconds) with the same result.  However I don't get the requisite "apinger: alarm canceled: FirewallAdminGateway" notification others have reported.  This keeps happening over and over and I'm at a loss to explain it.

      I'll be the first to admit that I'm very much an intermediate when it comes to this.  I'm hoping I'm missing an obvious error but the dearth of people reporting this issue vexes me.  I'm also more than willing to supply whatever additional information that might be needed to resolve this.

      Yeah, I know this is bad form for a first post, but I'm pretty desperate at this point.  Anything will help!

      1 Reply Last reply Reply Quote 0
      • L
        LinuxTracker
        last edited by

        Just to be clear, have you tried:

        Routing -> edit default gateway (e button)

        1. An Alternative monitor IP
          or
        2. Disable Gateway Monitoring

        ?

        1 Reply Last reply Reply Quote 0
        • luckman212L
          luckman212 LAYER 8
          last edited by

          I had this happen to me this morning on a 2.1.5 instance (physical hardware).  Not sure what is causing this either.  What I notice here as well at least on my system is that when this happens the clock timestamps on the system log entires seem to "jump" back and forth e.g

          Were you guys ever able to determine anything?

          1 Reply Last reply Reply Quote 0
          • P
            phil.davis
            last edited by

            The time thing is some issue with time zones and messages from some components logging UTC. I guess you are in a UTC+05:00 time zone. If you add 5 hours to those times then they look in order.
            I don't know about the check_reload_status happening!

            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

            1 Reply Last reply Reply Quote 0
            • luckman212L
              luckman212 LAYER 8
              last edited by

              Hmm so is it a 'best practice' to just set all the firewalls to UTC to work around this?

              1 Reply Last reply Reply Quote 0
              • P
                phil.davis
                last edited by

                @luckman212:

                Hmm so is it a 'best practice' to just set all the firewalls to UTC to work around this?

                I believe the time thing has been fixed. I only have 2.2 systems available to reboot right now. I rebooted 2.2 and the kernel messages and other application messages all have consistent times in my time zone.
                I am a bit surprised it happens in the latest 2.1.5 - but maybe it was only fixed in 2.2.

                As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                1 Reply Last reply Reply Quote 0
                • jimpJ
                  jimp Rebel Alliance Developer Netgate
                  last edited by

                  When you change the time zone only processes that get restarted will respect the new zone. For things like the kernel and some system daemons, a reboot is required to pick up the new zone change.

                  Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                  Need help fast? Netgate Global Support!

                  Do not Chat/PM for help!

                  1 Reply Last reply Reply Quote 0
                  • luckman212L
                    luckman212 LAYER 8
                    last edited by

                    Ah ha! That makes sense.  I always wondered why it sometimes seems to work as expected and other times not.  Thanks for that!

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