Bandwidthd after update 2.0.2 or 2.1-Beta

[heper]

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

[extide]

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]

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.

[crazie]

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

[derekv]

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).

[acald]

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.

[acald]

Has anyone reported this to the bug tracker?