Bandwidthd after update 2.0.2 or 2.1-Beta
I've recently updated 2 sites running 2.0.1 to 2.0.2 (amd64) and after the update bandwidthd was consuming 100% cpu load all the time.
i've tried to reinstall the package but the issue remained.
@ home i updated my 2.1 snapshot to todays build ( 2.1-BETA1 (i386) built on Sat Dec 22 08:15:29 EST 2012 ) and the same happened.
Currently i have removed the package until further notice.
It's not an issue for me, as i do not rely on this package, i just thought i should report it.
That is odd, as I am running that package on my 64bit pfSense box that recently went from 2.0.1 to 2.0.2, and I am not seeing this issue.
jnorell last edited by
Just a "me, too!" … we updated a box from the last -RELEASE to 2.0.2 and bandwidthd appears to cause the web interface to crash - ie. no more response on https, and the box has to be rebooted. Maybe it's "just" a cpu issue, though I'd kind of doubt it as it has 2 cores. Guess we'll uninstall for now.
I have the same exact issue. I updated to 2.0.2 from 2.0.1, and bandwidthd no longer works, taking 100% CPU, my hardware is an Intel E8400, with 8GB RAM. If I try to do anything w/ the settings page for bandwidthd, the webgui completely stops working, and I have to reboot the box to get it to come back. Tho I have not tried to killall php, and restart webconfig..
It looks like I'm getting something like this as well
last pid: 41238; load averages: 1.01, 1.01, 1.00 up 3+17:30:05 10:08:18 36 processes: 2 running, 34 sleeping CPU: 5.2% user, 0.0% nice, 19.9% system, 0.4% interrupt, 74.5% idle Mem: 57M Active, 20M Inact, 102M Wired, 52K Cache, 83M Buf, 787M Free Swap: 2048M Total, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 63644 root 1 118 0 17828K 2660K CPU1 1 89.4H 100.00% bandwidthd 243 root 1 76 20 7084K 1308K kqread 2 2:51 0.00% check_reload_status 17155 root 1 44 0 5964K 1492K select 3 2:24 0.00% apinger 38214 root 1 76 20 8292K 1756K wait 2 1:58 0.00% sh 31411 nobody 1 44 0 10152K 3260K select 3 0:30 0.00% dnsmasq 12943 root 1 44 0 14912K 2820K select 2 0:24 0.00% syslogd
Anyone figure this out?
Does disabling bandwidthd work?
(I have to wait till after hours to mess with it).
During the past couple weeks, my cable internet provider has been having problems where the connection would drop sending the cable modem into a re-initialize spasm that would constantly change the IP of my WAN connection from it's public IP to a private IP since the cable modem couldn't sync with the head end.
I've had to reboot pfSense 3 times over the past week and last night they had really bad problems and both the TV and internet were down overnight. At first, I wasn't sure what was causing the connectivity problem so I hunted around looking at different details. I stumbled upon the same CPU pegged out with bandwidthd at the top comsuming between 98-100%. The webconfigurator would respond for a few hours but eventually would slow down and finally cease responding. The box always responds to ping. I tried restarting the webconfigurator from the console but it didn't make a difference. I finally rebooted the pfSense box and then was able to check on the status again.
I finally went to bed and when I got up this morning the webconfigurator was nonresponsive and pfSense was not allowing packets through. Once it rebooted, everything worked like it should.
I've removed bandwidthd for now, but I would have no problem trying out a few things if someone has an idea. My gut feeling was maybe the constant changing of the interface's IP address was throwing bandwidthd for a loop. Maybe the writers of bandwidthd could weigh in on it.
Has anyone reported this to the bug tracker?