Check_reload_status: Reloading filter - Constantly reloading


  • 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!


  • Just to be clear, have you tried:

    Routing -> edit default gateway (e button)

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

    ?


  • 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?


  • 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!


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


  • @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.

  • Rebel Alliance Developer Netgate

    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.


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