https://redmine.pfsense.org/
https://redmine.pfsense.org/favicon.ico?1678052116
2012-07-22T20:56:07Z
pfSense bugtracker
pfSense - Bug #2555: check_reload_status consumes 100% CPU usage
https://redmine.pfsense.org/issues/2555?journal_id=9528
2012-07-22T20:56:07Z
Chris Buechler
cbuechler@gmail.com
<ul><li><strong>Affected Version</strong> changed from <i>2.1-IPv6</i> to <i>2.1</i></li></ul>
pfSense - Bug #2555: check_reload_status consumes 100% CPU usage
https://redmine.pfsense.org/issues/2555?journal_id=9711
2012-08-29T14:45:21Z
Jim Pingle
<ul></ul><p>When this happens, please capture the full output of "ps uxawww" and attach it here. Odds are there are a batch of processes either calling, or launched by, check_reload_status and it would help to see which ones they are.</p>
pfSense - Bug #2555: check_reload_status consumes 100% CPU usage
https://redmine.pfsense.org/issues/2555?journal_id=9716
2012-08-29T19:25:03Z
Snowy Maslov
<ul></ul><pre>
[2.1-BETA0][admin@pegacorn.snowy.org]/root(7): ps uxawww
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
root 11 253.2 0.0 0 32 ?? RL Wed05AM 4321:39.37 [idle]
root 319 100.0 0.0 3416 1164 ?? RNs Wed05AM 1730:57.50 /usr/local/sbin/check_reload_status
root 12 2.7 0.0 0 232 ?? WL Wed05AM 72:29.92 [intr]
root 0 0.0 0.0 0 88 ?? DLs Wed05AM 0:12.26 [kernel]
root 1 0.0 0.0 1888 272 ?? SLs Wed05AM 0:05.75 /sbin/init --
root 2 0.0 0.0 0 8 ?? DL Wed05AM 0:00.02 [g_event]
root 3 0.0 0.0 0 8 ?? DL Wed05AM 1:33.13 [g_up]
root 4 0.0 0.0 0 8 ?? DL Wed05AM 2:35.12 [g_down]
root 5 0.0 0.0 0 8 ?? DL Wed05AM 0:00.00 [crypto]
root 6 0.0 0.0 0 8 ?? DL Wed05AM 0:00.00 [crypto returns]
root 7 0.0 0.0 0 8 ?? DL Wed05AM 0:01.20 [sctp_iterator]
root 8 0.0 0.0 0 8 ?? DL Wed05AM 0:08.81 [pfpurge]
root 9 0.0 0.0 0 8 ?? DL Wed05AM 0:00.00 [xpt_thrd]
root 10 0.0 0.0 0 8 ?? DL Wed05AM 0:00.00 [audit]
root 13 0.0 0.0 0 32 ?? DL Wed05AM 0:00.92 [ng_queue]
root 14 0.0 0.0 0 8 ?? DL Wed05AM 4:00.69 [yarrow]
root 15 0.0 0.0 0 264 ?? DL Wed05AM 0:03.97 [usb]
root 16 0.0 0.0 0 8 ?? DL Wed05AM 0:01.18 [pagedaemon]
root 17 0.0 0.0 0 8 ?? DL Wed05AM 0:00.00 [vmdaemon]
root 18 0.0 0.0 0 8 ?? DL Wed05AM 0:00.00 [pagezero]
root 19 0.0 0.0 0 8 ?? DL Wed05AM 0:00.19 [idlepoll]
root 20 0.0 0.0 0 8 ?? DL Wed05AM 0:00.66 [bufdaemon]
root 21 0.0 0.0 0 8 ?? DL Wed05AM 2:56.38 [syncer]
root 22 0.0 0.0 0 8 ?? DL Wed05AM 0:02.43 [vnlru]
root 23 0.0 0.0 0 8 ?? DL Wed05AM 0:00.82 [softdepflush]
root 39 0.0 0.0 0 8 ?? DL Wed05AM 3:58.06 [md0]
root 321 0.0 0.0 3416 976 ?? IN Wed05AM 0:00.00 check_reload_status: Monitoring daemon of check_reload_status
root 332 0.0 0.1 3936 2124 ?? Is Wed05AM 0:00.00 /sbin/devd
root 4363 0.0 0.1 6736 4540 ?? S Wed05AM 8:37.83 /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf
root 5029 0.0 0.1 8956 3692 ?? Ss Wed05AM 0:02.18 /usr/local/sbin/mpd5 -b -k -d /var/etc -f mpd_wan.conf -p /var/run/pppoe_wan.pid -s ppp pppoeclient
root 6045 0.0 0.5 59008 17024 ?? S 8:57AM 0:25.78 /usr/local/bin/php
root 6134 0.0 0.1 5344 2756 ?? Is Wed05AM 0:00.00 /usr/sbin/sshd
root 11168 0.0 0.0 3328 1000 ?? Is Wed05AM 0:00.00 /usr/local/bin/minicron 240 /var/run/ping_hosts.pid /usr/local/bin/ping_hosts.sh
root 11570 0.0 0.0 3328 1048 ?? I Wed05AM 0:00.11 minicron: helper /usr/local/bin/ping_hosts.sh (minicron)
root 11575 0.0 0.0 3328 1000 ?? Is Wed05AM 0:00.00 /usr/local/bin/minicron 3600 /var/run/expire_accounts.pid /etc/rc.expireaccounts
root 12017 0.0 0.0 3328 1048 ?? I Wed05AM 0:00.01 minicron: helper /etc/rc.expireaccounts (minicron)
root 12260 0.0 0.0 3328 1000 ?? Is Wed05AM 0:00.00 /usr/local/bin/minicron 86400 /var/run/update_alias_url_data.pid /etc/rc.update_alias_url_data
root 12373 0.0 0.0 3328 1048 ?? I Wed05AM 0:00.00 minicron: helper /etc/rc.update_alias_url_data (minicron)
dhcpd 13056 0.0 0.2 8448 5372 ?? Ss Wed05AM 0:06.46 /usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid em0
dhcpd 14324 0.0 0.1 7680 4232 ?? Ss Wed05AM 0:05.58 /usr/local/sbin/dhcpd -6 -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpdv6.conf -pf /var/run/dhcpdv6.pid em0
root 14840 0.0 0.0 1584 860 ?? Is Wed05AM 0:00.00 /usr/local/sbin/dhcpleases6 -c /usr/local/bin/php -f /usr/local/sbin/prefixes.php|/bin/sh -l /var/dhcpd/var/db/dhcpd6.leases
root 15345 0.0 0.0 3328 1252 ?? Ss Wed05AM 0:15.11 /usr/local/sbin/radvd -C /var/etc/radvd.conf -m syslog
root 15385 0.0 0.0 3544 1192 ?? Is Wed05AM 0:00.02 /usr/local/sbin/sshlockout_pf 15
root 15869 0.0 0.0 3328 1340 ?? Is Wed05AM 0:00.18 /usr/local/sbin/dhcpleases -l /var/dhcpd/var/db/dhcpd.leases -d snowy.org -p /var/run/dnsmasq.pid -h /var/etc/hosts
root 15901 0.0 0.0 3328 1240 ?? Ss Wed05AM 0:56.37 /usr/local/sbin/dhcp6c -d -c /var/etc/dhcp6c_wan.conf pppoe0
nobody 16426 0.0 0.1 5576 2396 ?? S Wed05AM 0:39.31 /usr/local/sbin/dnsmasq --local-ttl 1 --all-servers --rebind-localhost-ok --stop-dns-rebind --dns-forward-max=5000 --cache-size=10000 --dhcp-hostsfile=/var/etc/hosts
root 18842 0.0 0.2 6132 6156 ?? Ss Wed05AM 0:41.36 /usr/local/bin/ntpd -g -c /var/etc/ntpd.conf
root 19213 0.0 0.1 8096 3560 ?? Ss 10:21AM 0:00.13 sshd: admin@pts/0 (sshd)
root 22551 0.0 0.1 4976 2068 ?? Ss Wed05AM 1:50.22 /usr/sbin/syslogd -c -c -l /var/dhcpd/var/run/log -f /var/etc/syslog.conf
root 33971 0.0 0.4 20476 13108 ?? SNs 11:13PM 0:36.60 /usr/local/sbin/ipfw-classifyd -n 8 -q 700 -c /tmp/VoIP_High_Priority.l7 -p 50196 -P /usr/local/share/protocols
root 41112 0.0 0.6 59008 17552 ?? S 10:20AM 0:02.18 /usr/local/bin/php
root 44990 0.0 0.0 3328 1328 ?? Ss 10:24AM 0:00.00 /usr/local/sbin/apinger -c /var/etc/apinger.conf
root 45030 0.0 0.0 0 0 ?? Z 10:24AM 0:00.00 <defunct>
root 48450 0.0 0.0 1576 784 ?? IN 10:23AM 0:00.00 sleep 60
root 50884 0.0 0.0 3328 1356 ?? Is Wed05AM 0:00.00 /usr/local/bin/rsync --daemon
root 51925 0.0 0.0 3364 1416 ?? Ss Wed05AM 0:33.67 /usr/local/sbin/miniupnpd -f /var/etc/miniupnpd.conf -P /var/run/miniupnpd.pid
root 52108 0.0 0.0 3448 1364 ?? Ss Wed05AM 0:05.93 /usr/sbin/inetd -wW -R 0 -a 127.0.0.1 /var/etc/inetd.conf
root 52473 0.0 0.0 3420 1340 ?? Ss Wed05AM 0:00.30 /usr/sbin/cron -s
root 57036 0.0 0.5 22524 15700 ?? SNs 6:59PM 0:49.54 /usr/local/sbin/ipfw-classifyd -n 8 -q 700 -c /tmp/P2P_Bulk_Transfer.l7 -p 42570 -P /usr/local/share/protocols
root 15148 0.0 0.1 3784 1576 v0 Is Wed05AM 0:00.03 login [pam] (login)
root 15601 0.0 0.0 3708 1280 v0 I Wed05AM 0:00.01 -sh (sh)
root 16793 0.0 0.0 3708 1280 v0 I+ Wed05AM 0:00.01 /bin/sh /etc/rc.initial
root 21328 0.0 0.1 6952 4188 v0- S Wed05AM 0:09.38 /usr/sbin/tcpdump -s 256 -v -l -n -e -ttt -i pflog0
root 21555 0.0 0.0 3328 904 v0- S Wed05AM 0:11.96 logger -t pf -p local0.info
root 49001 0.0 0.0 3708 1308 v0- IN Wed05AM 0:25.65 /bin/sh /var/db/rrd/updaterrd.sh
root 36699 0.0 0.0 3708 1288 0 Is 10:21AM 0:00.01 /bin/sh /etc/rc.initial
root 45338 0.0 0.0 3468 1236 0 R+ 10:24AM 0:00.00 ps uxawww
root 56283 0.0 0.1 3736 2244 0 S 10:21AM 0:00.03 /bin/tcsh
[2.1-BETA0][admin@pegacorn.snowy.org]/root(8):
</pre>
<p>Current build:<br />2.1-BETA0 (i386) <br />built on Fri Aug 24 08:48:52 EDT 2012 <br />FreeBSD 8.3-RELEASE-p4</p>
pfSense - Bug #2555: check_reload_status consumes 100% CPU usage
https://redmine.pfsense.org/issues/2555?journal_id=9737
2012-09-05T17:27:20Z
Gianluca Toso
<ul></ul><p>I confirm the bug at least on all recent 64bit builds and in the last too:<br />2.1-BETA0 (amd64)<br />built on Tue Sep 4 16:39:48 EDT 2012</p>
<p>My platform:<br />vmware workstation (tested on 8 and 9, hw version 8)<br />Intel(R) Core(TM) i5 CPU 760 @ 2.80GHz<br />512MB RAM, 2 ethernet</p>
<p>The problem started when I enable prefix delegation on my cisco,<br />before i had only neighbor discovery router advertisements (ipv6 nd prefix ...) and pfsense at default dhcpv6.</p>
<p>Then I added:<br />ipv6 nd other-config-flag<br />ipv6 dhcp server IPV6_LAN<br />ipv6 dhcp pool IPV6_LAN<br /> prefix-delegation pool IPV6_POOL<br /> dns-server ...<br /> domain-name ...<br />ipv6 local pool IPV6_POOL .../48 64</p>
<p>And the pfsense problems started,<br />even if I change in pfsense "DHCPv6 Prefix Delegation size" from 64 to none the problem persists.<br />Then only way is to set WAN to SLAAC, but then (at first reboot) the delegated IPv6 prefix disappears from pfsense.</p>
<pre>
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
root 259 94.0 0.3 6988 1328 ?? RNs 2:59PM 526:15.92 /usr/local/sbin/check_reload_status
root 0 0.0 0.0 0 144 ?? DLs 2:59PM 0:03.27 [kernel]
root 1 0.0 0.1 3204 516 ?? SLs 2:59PM 0:00.58 /sbin/init --
root 2 0.0 0.0 0 16 ?? DL 2:59PM 0:00.00 [g_event]
root 3 0.0 0.0 0 16 ?? DL 2:59PM 0:02.27 [g_up]
root 4 0.0 0.0 0 16 ?? DL 2:59PM 0:35.34 [g_down]
root 5 0.0 0.0 0 16 ?? DL 2:59PM 0:00.00 [crypto]
root 6 0.0 0.0 0 16 ?? DL 2:59PM 0:00.00 [crypto returns]
root 7 0.0 0.0 0 16 ?? DL 2:59PM 0:00.00 [mpt_recovery0]
root 8 0.0 0.0 0 16 ?? DL 2:59PM 0:00.07 [fdc0]
root 9 0.0 0.0 0 16 ?? IL 2:59PM 0:00.00 [HgfsKReqWorker]
root 10 0.0 0.0 0 16 ?? DL 2:59PM 0:00.00 [audit]
root 11 0.0 0.0 0 16 ?? RL 2:59PM 0:02.41 [idle]
root 12 0.0 0.1 0 272 ?? WL 2:59PM 0:44.78 [intr]
root 13 0.0 0.0 0 16 ?? DL 2:59PM 0:00.00 [ng_queue]
root 14 0.0 0.0 0 16 ?? DL 2:59PM 0:00.74 [yarrow]
root 15 0.0 0.0 0 128 ?? DL 2:59PM 0:01.06 [usb]
root 16 0.0 0.0 0 16 ?? DL 2:59PM 0:00.04 [sctp_iterator]
root 17 0.0 0.0 0 16 ?? DL 2:59PM 0:00.16 [pfpurge]
root 18 0.0 0.0 0 16 ?? DL 2:59PM 0:00.00 [xpt_thrd]
root 19 0.0 0.0 0 16 ?? DL 2:59PM 0:00.01 [pagedaemon]
root 20 0.0 0.0 0 16 ?? DL 2:59PM 0:00.00 [vmdaemon]
root 21 0.0 0.0 0 16 ?? DL 2:59PM 0:00.00 [pagezero]
root 22 0.0 0.0 0 16 ?? DL 2:59PM 0:00.02 [idlepoll]
root 23 0.0 0.0 0 16 ?? DL 2:59PM 0:00.06 [bufdaemon]
root 24 0.0 0.0 0 16 ?? DL 2:59PM 0:00.59 [syncer]
root 25 0.0 0.0 0 16 ?? DL 2:59PM 0:00.06 [vnlru]
root 26 0.0 0.0 0 16 ?? DL 2:59PM 0:00.06 [softdepflush]
root 42 0.0 0.0 0 16 ?? DL 2:59PM 0:01.56 [md0]
root 261 0.0 0.2 6988 1172 ?? IN 2:59PM 0:00.00 check_reload_status: Monitoring daemon of check_reload_status
root 273 0.0 0.6 5248 3136 ?? Is 2:59PM 0:00.00 /sbin/devd
root 5158 0.0 0.3 6952 1456 ?? Is 2:59PM 0:00.00 dhclient: em0 [priv] (dhclient)
root 8602 0.0 0.7 15344 3548 ?? Is 2:59PM 0:00.00 /usr/sbin/sshd
root 11382 0.0 0.2 5864 1108 ?? Is 2:59PM 0:00.00 /usr/local/bin/minicron 240 /var/run/ping_hosts.pid /usr/local/bin/ping_hosts.sh
root 11645 0.0 0.2 5864 1168 ?? I 2:59PM 0:00.02 minicron: helper /usr/local/bin/ping_hosts.sh (minicron)
root 11723 0.0 0.2 5864 1108 ?? Is 2:59PM 0:00.00 /usr/local/bin/minicron 3600 /var/run/expire_accounts.pid /etc/rc.expireaccounts
_dhcp 11753 0.0 0.3 6952 1616 ?? Ss 2:59PM 0:00.71 dhclient: em0 (dhclient)
root 12201 0.0 0.2 5864 1168 ?? I 2:59PM 0:00.00 minicron: helper /etc/rc.expireaccounts (minicron)
root 12391 0.0 0.3 5860 1460 ?? Ss 2:59PM 0:07.68 /usr/local/sbin/dhcp6c -d -c /var/etc/dhcp6c_wan.conf em0
root 12399 0.0 0.2 5864 1108 ?? Is 2:59PM 0:00.00 /usr/local/bin/minicron 86400 /var/run/update_alias_url_data.pid /etc/rc.update_alias_url_data
root 13028 0.0 0.2 5864 1156 ?? I 2:59PM 0:00.00 minicron: helper /etc/rc.update_alias_url_data (minicron)
root 17238 0.0 0.3 7116 1308 ?? Is 2:59PM 0:00.00 /usr/local/sbin/sshlockout_pf 15
root 18359 0.0 0.6 14864 2800 ?? Ss 2:59PM 0:04.45 /usr/sbin/syslogd -c -c -l /var/dhcpd/var/run/log -f /var/etc/syslog.conf
root 20844 0.0 0.3 9064 1560 ?? Ss 2:59PM 0:00.48 /usr/sbin/inetd -wW -R 0 -a 127.0.0.1 /var/etc/inetd.conf
root 21887 0.0 1.4 57488 6780 ?? S 2:59PM 0:10.31 /usr/pbi/open-vm-tools-nox11-amd64/bin/vmtoolsd -c /usr/local/share/vmware-tools/tools.conf -p /usr/local/lib/open-vm-tools/plugins/vmsvc
root 31941 0.0 1.1 23900 5736 ?? S 2:59PM 0:00.69 /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf
root 32464 0.0 7.2 109932 35912 ?? I 2:59PM 0:00.24 /usr/local/bin/php
root 37117 0.0 8.0 109932 40264 ?? S 2:59PM 0:01.45 /usr/local/bin/php
dhcpd 39796 0.0 1.4 13088 7096 ?? Ss 2:59PM 0:00.41 /usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid em1
dhcpd 41922 0.0 1.0 11168 4936 ?? Ss 2:59PM 0:00.52 /usr/local/sbin/dhcpd -6 -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpdv6.conf -pf /var/run/dhcpdv6.pid em1
root 42751 0.0 0.2 2804 1024 ?? Is 2:59PM 0:00.00 /usr/local/sbin/dhcpleases6 -c /usr/local/bin/php -f /usr/local/sbin/prefixes.php|/bin/sh -l /var/dhcpd/var/db/dhcpd6.leases
root 43474 0.0 1.4 14020 6940 ?? Ss 2:59PM 0:03.95 /usr/local/bin/ntpd -g -c /var/etc/ntpd.conf
root 44016 0.0 0.3 5864 1460 ?? Ss 2:59PM 0:02.03 /usr/local/sbin/radvd -C /var/etc/radvd.conf -m syslog
nobody 47754 0.0 0.6 10184 3000 ?? I 2:59PM 0:00.01 /usr/local/sbin/dnsmasq --local-ttl 1 --all-servers --rebind-localhost-ok --stop-dns-rebind --dns-forward-max=5000 --cache-size=10000
root 51703 0.0 0.2 2796 1000 ?? SN 12:21AM 0:00.00 sleep 60
root 54658 0.0 0.4 8376 1844 ?? S 12:21AM 0:00.00 /bin/sh /var/etc/dhcp6c_wan_script.sh
root 54832 0.0 7.6 118124 38324 ?? S 12:21AM 0:00.10 /usr/local/bin/php -f /etc/rc.newwanipv6 wan
root 61791 0.0 0.9 26244 4352 ?? Ss 12:18AM 0:00.03 sshd: root@pts/0 (sshd)
root 61855 0.0 0.3 8008 1584 ?? Is 2:59PM 0:00.03 /usr/sbin/cron -s
root 14485 0.0 0.4 19560 1832 v0 Is 2:59PM 0:00.00 login [pam] (login)
root 17325 0.0 0.3 8376 1704 v0 I 2:59PM 0:00.00 -sh (sh)
root 17591 0.0 0.5 11824 2632 v0- S 2:59PM 0:00.49 /usr/sbin/tcpdump -s 256 -v -l -n -e -ttt -i pflog0
root 17887 0.0 0.2 5860 1044 v0- S 2:59PM 0:00.28 logger -t pf -p local0.info
root 18708 0.0 0.3 8376 1704 v0 I+ 2:59PM 0:00.00 /bin/sh /etc/rc.initial
root 55506 0.0 0.3 8376 1744 v0- SN 2:59PM 0:01.19 /bin/sh /var/db/rrd/updaterrd.sh
root 2148 0.0 0.4 8376 1816 0 Is 12:18AM 0:00.00 -sh (sh)
root 2719 0.0 0.4 8376 1820 0 I 12:18AM 0:00.00 /bin/sh /etc/rc.initial
root 11778 0.0 0.5 8348 2756 0 R 12:18AM 0:00.01 /bin/tcsh
root 56393 0.0 0.3 8072 1548 0 R+ 12:21AM 0:00.00 ps uxawww
</pre>
<pre>
Sep 6 00:22:49 php: : ROUTING: setting IPv6 default route to fe80::21b:cff:fec2:5f30%em0
Sep 6 00:22:49 php: : ROUTING: setting default route to 192.168.66.250
Sep 6 00:22:49 php: : dhcp6 lan with ipv6 address XXXX:XXXX:XXXX::1 based on wan
Sep 6 00:22:49 php: : Interface lan configured via wan type dhcp6
Sep 6 00:22:49 php: : interface lan depends on wan, configuring
Sep 6 00:22:49 php: : rc.newwanipv6: on (IP address: XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX) (interface: wan) (real interface: em0).
Sep 6 00:22:49 php: : rc.newwanipv6: Informational is starting.
Sep 6 00:22:47 dhcp6c[12391]: update_ia: status code for NA-0: no addresses
Sep 6 00:22:46 php: : ROUTING: setting IPv6 default route to fe80::21b:cff:fec2:5f30%em0
Sep 6 00:22:46 php: : ROUTING: setting default route to 192.168.66.250
Sep 6 00:22:46 php: : dhcp6 lan with ipv6 address XXXX:XXXX:XXXX::1 based on wan
Sep 6 00:22:46 php: : Interface lan configured via wan type dhcp6
Sep 6 00:22:46 php: : interface lan depends on wan, configuring
Sep 6 00:22:46 php: : rc.newwanipv6: on (IP address: XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX) (interface: wan) (real interface: em0).
Sep 6 00:22:46 php: : rc.newwanipv6: Informational is starting.
Sep 6 00:22:45 dhcp6c[12391]: update_ia: status code for NA-0: no addresses
Sep 6 00:22:44 php: : ROUTING: setting IPv6 default route to fe80::21b:cff:fec2:5f30%em0
Sep 6 00:22:44 php: : ROUTING: setting default route to 192.168.66.250
Sep 6 00:22:44 php: : dhcp6 lan with ipv6 address XXXX:XXXX:XXXX::1 based on wan
Sep 6 00:22:44 php: : Interface lan configured via wan type dhcp6
Sep 6 00:22:44 php: : interface lan depends on wan, configuring
Sep 6 00:22:44 php: : rc.newwanipv6: on (IP address: XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX) (interface: wan) (real interface: em0).
Sep 6 00:22:44 php: : rc.newwanipv6: Informational is starting.
Sep 6 00:22:42 dhcp6c[12391]: update_ia: status code for NA-0: no addresses
...
</pre>
<p>and so on</p>
pfSense - Bug #2555: check_reload_status consumes 100% CPU usage
https://redmine.pfsense.org/issues/2555?journal_id=10145
2012-12-18T08:10:07Z
Ermal Luçi
eri@pfsense.org
<ul></ul><p>Is this still valid issue on recent snaps?<br />If yes, than a look at why frequent updates are present there!</p>
pfSense - Bug #2555: check_reload_status consumes 100% CPU usage
https://redmine.pfsense.org/issues/2555?journal_id=10401
2013-01-25T16:30:18Z
Ermal Luçi
eri@pfsense.org
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li></ul><p>This seems occasional since not many have reported it.</p>
pfSense - Bug #2555: check_reload_status consumes 100% CPU usage
https://redmine.pfsense.org/issues/2555?journal_id=10820
2013-02-17T09:38:01Z
Amy Alvarez
epoxy@fif3.com
<ul></ul><p>FYI this is still happening to me on 2.0.2 release.</p>
pfSense - Bug #2555: check_reload_status consumes 100% CPU usage
https://redmine.pfsense.org/issues/2555?journal_id=10821
2013-02-17T09:41:55Z
Amy Alvarez
epoxy@fif3.com
<ul></ul><p>Amy Alvarez wrote:</p>
<blockquote>
<p>FYI this is still happening to me on 2.0.2 release.</p>
</blockquote>
<p>I do have captive portal enabled, but I do not have vouchers enabled.</p>
pfSense - Bug #2555: check_reload_status consumes 100% CPU usage
https://redmine.pfsense.org/issues/2555?journal_id=10874
2013-02-21T19:35:13Z
Ben Harris
mail@bharr.is
<ul></ul><p>Tracked down the issue to dhcp6c calling rc.newwanipv6 which called "filter reload" on check_reload_status.</p>
<p>The default dhcp6 config asks for stateful addressing ia-na, which my ISP doesn't provide, this causes dhcp6c to retry every 5 seconds, which results in check_reload_status getting swamped with filter reloads.</p>
<p>Fixed it in my case by commenting out the two ia-na lines in interfaces.inc.</p>
pfSense - Bug #2555: check_reload_status consumes 100% CPU usage
https://redmine.pfsense.org/issues/2555?journal_id=11028
2013-03-05T21:03:54Z
Chris Buechler
cbuechler@gmail.com
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Resolved</i></li></ul><p>There are a wide range of issues unrelated to check_reload_status that can cause this. At the time of the original report there were several that have since been fixed. As JimP noted on the forum:</p>
<pre>
check_reload_status itself doesn't tend to be the problem in these cases. Something (such as rc.newwanip) calls pfSctl which routes a request through check_reload_status which in turn tries to take another action - the problem seems to happen more often when there are either:
(a) a lot of programs trying to make calls through check_reload_status
(b) whatever check_reload_status is calling is not behaving as expected
</pre>
<p>if there are any outstanding issues that cause check_reload_status to get hammered, the source issue needs to be tracked down and have its own ticket(s) opened.</p>
pfSense - Bug #2555: check_reload_status consumes 100% CPU usage
https://redmine.pfsense.org/issues/2555?journal_id=11029
2013-03-05T21:06:23Z
Snowy Maslov
<ul></ul><p>Unfortunately I have moved on from pfsense so I can't recheck to see if this has been resolved in later versions still the above sounds like it would have solved - best left resolved and if other are still having issues they can re-open against the current version.</p>
pfSense - Bug #2555: check_reload_status consumes 100% CPU usage
https://redmine.pfsense.org/issues/2555?journal_id=11306
2013-04-15T03:35:26Z
Thomas Gruber
tgruber@cms-it.de
<ul><li><strong>File</strong> <a href="/attachments/756">ps-auxwww.log</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/756/ps-auxwww.log">ps-auxwww.log</a> added</li><li><strong>File</strong> <a href="/attachments/757">system.log</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/757/system.log">system.log</a> added</li></ul><p>This still happens to me on <br />2.1-BETA1 (amd64)<br />built on Sun Apr 14 16:35:09 EDT 2013<br />FreeBSD 8.3-RELEASE-p7</p>
<p>Interestingly the CPU load produced by check_reload_status varies between 20% and 100%. Also the System reloads the rules over and over every 10 seconds. This can be observed in the System log i attached. From the log i can also read that the High load began when setting the IPv6 Gateway.</p>
<p>By now i deleted the v6 Gateway. <br />and Killed the check_reload_status process (gets restarted by WebUI)<br />and Rebooted the box<br />-> All this did not terminate the high load...</p>
<p>output of ps auxwww is also attached of course ;-)</p>
pfSense - Bug #2555: check_reload_status consumes 100% CPU usage
https://redmine.pfsense.org/issues/2555?journal_id=11307
2013-04-15T03:51:41Z
Chris Buechler
cbuechler@gmail.com
<ul></ul><p>the issue in this ticket is resolved. check_reload_status having high CPU usage in current snapshots is a symptom of some other problem, not a problem in itself. Please post information to the 2.1 board on the forum so someone can help you troubleshoot the real cause.</p>