Issues with newest 2.0.3-PRERELEASE
-
I updated my pfSense Box 2 days ago with the newest PRERELEASE Build:
2.0.3-PRERELEASE (i386)
built on Fri Apr 5 09:07:14 EDT 2013
FreeBSD 8.1-RELEASE-p13The System crashed yesterday for the first time and of course i've submitted the crash resport.
If you've received a crash report from 24.134.x.x, that was me.What i've noticed is that one openvpn connection runs a bit weird and the cpu usage wents up for no reason since the update:
i wasnt even at home on monday and sleeping today when the processor usage went up, so no traffic or WAN usage at all by any device.
This openVPN Connection may cause the issue:
Restarted everything at 9.30am and since then its running fine again, but still strange, because it already happened yesterday. No crash report was generated today, since i rebooted my pfsense box just before it could crash.
-
your crash report shows repeated link cycling on em1. Some problem there with what it's connected to, its cable, the NIC itself, or something else causing its link to go up and down over and over. That would cause the increase CPU usage since when a NIC regains link a number of things have to be done and it'd be constantly doing those same things over and over and over.
Whether that's directly or indirectly related to the kernel panic I'm not sure. The link cycling is the first thing to troubleshoot and resolve.
-
Ok thanks, bit of strange that it just happenes after an upgrade.
Could you tell me, what /usr/local/sbin/check_reload_status does?
Happened today again, router hang up and "check_reload_status" was producing a lot of CPU usage. -
check_reload_status is a command broker of sorts. It accepts commands from scripts and handles actions based on those commands.
When your link goes down/up, it fires off rc.newwanip. When that happens, some commands run that tell check_reload_status to do things like update firewall rules and so on, then check_reload_status will run the commands as needed.
What you're seeing is a side effect of some other issue, check_reload_status on its own isn't actually the problem, it's whatever issued the large number of commands to it.