Bandwidthd after update 2.0.2 or 2.1-Beta
-
Hi,
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.Kind regards,
Jeroen
-
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.
-
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% syslogdAnyone 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?
