Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Bandwidthd issues?

    Scheduled Pinned Locked Moved Traffic Monitoring
    60 Posts 17 Posters 18.2k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • arrmoA
      arrmo
      last edited by

      Hi,

      FYI - did a complete uninstall of bandwidthd, then reinstalled. All looked good, then I rebooted … :(. Again I had two copies of bandwidthd running, and it broke my GUI.

      So the reboot after seems critical (to demonstrate the problem).

      Thanks.

      1 Reply Last reply Reply Quote 0
      • C
        cmb
        last edited by

        Anyone who can replicate the issue with bandwidthd breaking the web interface, is there anything unusual about your setup? Seems it's easy for some to replicate, but most of us, including myself with at least a handful of 2.2 systems running bandwidthd, have never been able to replicate. Could someone share a config backup from a system that exhibits the issue?

        1 Reply Last reply Reply Quote 0
        • arrmoA
          arrmo
          last edited by

          Yep, I can get that to you - but is there an easy way to remove any sensitive information?

          Thanks!

          1 Reply Last reply Reply Quote 0
          • R
            reggie14
            last edited by

            For what its worth, installing bandwidthd seemed to bork my webGUI too.  More specifically, after installation I started configuring it (i.e., selecting the LAN interface and identifying the subnet), I hit save and that's when the webGUI went down.

            I restarted the pfsense box and managed to get back in.  bandwidthd isn't running, and I don't plan to enable it for fear of not being able to get back in next time it goes down.

            My setup isn't hugely special.  I'm running 2.2-RC (amd64), Jan 02 build, with packages apinger, darkstat and snort.

            1 Reply Last reply Reply Quote 0
            • B
              Brrm
              last edited by

              @reggie14:

              For what its worth, installing bandwidthd seemed to bork my webGUI too.  More specifically, after installation I started configuring it (i.e., selecting the LAN interface and identifying the subnet), I hit save and that's when the webGUI went down.

              I restarted the pfsense box and managed to get back in.  bandwidthd isn't running, and I don't plan to enable it for fear of not being able to get back in next time it goes down.

              My setup isn't hugely special.  I'm running 2.2-RC (amd64), Jan 02 build, with packages apinger, darkstat and snort.

              Same thing happened to me. But after a reboot it's running without issues.

              1 Reply Last reply Reply Quote 0
              • arrmoA
                arrmo
                last edited by

                Hi,

                Do you have bandwidthd running on boot (i.e. is it enabled)? That may be your "fix" - below is why I say this …

                I tried a few cases,

                1. Upgrade my release - breaks on reboot, and 2 copies of bandwidthd are running.

                2. Reboot, with bandwidthd enabled. Again, 2 copies are running, and I can see this in the log,
                  Jan  5 13:24:37 pfSense bandwidthd: Monitoring subnet 255.255.255.0 with netmask 255.255.255.0
                  Jan  5 13:24:37 pfSense bandwidthd: Monitoring subnet 255.255.255.0 with netmask 255.255.255.0
                  Jan  5 13:24:37 pfSense bandwidthd: Opening bge0
                  Jan  5 13:24:37 pfSense bandwidthd: Packet Encoding: Ethernet
                  Jan  5 13:24:37 pfSense bandwidthd: Opening bge0
                  Jan  5 13:24:37 pfSense bandwidthd: Packet Encoding: Ethernet

                3. Disable bandwidthd, reboot ... then all is good, GUI doesn't break. So bandwidthd seems to be the culprit. I then manually started bandwidthd (from the GUI ... enable and save). Only a single copy runs (log below), and GUI stays up,
                  Jan  6 06:58:51 pfSense bandwidthd: Monitoring subnet 255.255.255.0 with netmask 255.255.255.0
                  Jan  6 06:58:51 pfSense bandwidthd: Opening bge0
                  Jan  6 06:58:51 pfSense bandwidthd: Packet Encoding: Ethernet

                So it seems that reboot with bandwidhd is the issue ... and 2 copies of bandwidthd are started for some reason (confirmed by ps aux, and also in the logs). Any idea why this happens (and how to fix it)?

                Thanks!

                1 Reply Last reply Reply Quote 0
                • arrmoA
                  arrmo
                  last edited by

                  Hi,

                  OK, perhaps another interesting finding here (that I admit, I stumbled on to accidentally …  ;)).

                  In the case where things break, I see the following in the logs. I did make this happen once with manual (command line) restarts of bandwidthd, but can't seem to make it happen again ... :(.

                  Jan 6 09:28:11 lighttpd[27258]: (mod_fastcgi.c.1754) connect failed: No such file or directory on unix:/var/run/php-fpm.socket
                  Jan 6 09:28:11 lighttpd[27258]: (mod_fastcgi.c.3021) backend died; we'll disable it for 1 seconds and send the request to another backend instead: reconnects: 0 load: 1
                  Jan 6 09:28:14 lighttpd[27258]: (mod_fastcgi.c.2848) fcgi-server re-enabled: unix:/var/run/php-fpm.socket

                  Followed by,
                  sshlockout[43240]: sshlockout/webConfigurator v3.0 starting up

                  Thoughts? I think the sshlockout may be what is causing this, but why is it happening?

                  Thanks!

                  1 Reply Last reply Reply Quote 0
                  • arrmoA
                    arrmo
                    last edited by

                    Hi,

                    OK, a bit more here - hoping to get some thoughts on this … ;).

                    It seems that the GUI is broken when I stop the two operating bandwidthd processes after boot (more on this below). When I boot up, there are two bandwidthd processes ... does anyone else see this? I did an uninstall / reinstall, get the same thing. This itself doesn't kill the GUI, it's when I ssh in and stop bandwidthd ... then the GUI breaks.

                    If I restart php-fpm, then after that I can can stop and start bandwidthd as much as I want - the GUI stays up.

                    Thoughts?

                    Thanks!

                    1 Reply Last reply Reply Quote 0
                    • arrmoA
                      arrmo
                      last edited by

                      And one more thing … stopping bandwidthd also kills ntopng (not just the GUI / php-fpm). Very odd ... :(

                      1 Reply Last reply Reply Quote 0
                      • arrmoA
                        arrmo
                        last edited by

                        Hi,

                        I have a change I want to try (locally), but it seems that files inside /usr/local/etc/rc.d get recreated on boot - and I admit, I can't find the source file (in text format at least … ;)). If anyone has any pointers I'd appreciate it, just trying to debug.

                        Thanks!

                        1 Reply Last reply Reply Quote 0
                        • arrmoA
                          arrmo
                          last edited by

                          Hi,

                          Hoping someone else is smarter than me here (that wouldn't be difficult … :(). I want to change /usr/local/etc/rc.d/bandwidthd.sh as follows,

                          Current:
                          rc_start() {
                                  cd /usr/pbi/bandwidthd-amd64/local/bandwidthd
                          LD_LIBRARY_PATH=/usr/pbi/bandwidthd-amd64/local/lib /usr/pbi/bandwidthd-amd64/local/bandwidthd/bandwidthd
                          cd -
                          }

                          Updated:
                          rc_start() {
                                  cd /usr/pbi/bandwidthd-amd64/local/bandwidthd
                                  if [ -z "ps auxw | grep "[/]usr/pbi/bandwidthd-amd64/local/bandwidthd/bandwidthd"|awk '{print $2}'" ];then
                                          LD_LIBRARY_PATH=/usr/pbi/bandwidthd-amd64/local/lib /usr/pbi/bandwidthd-amd64/local/bandwidthd/bandwidthd
                                  fi
                                  cd -
                          }

                          This is just to avoid multiple copies of bandwidthd from being started (as I see all the time). But I can't figure out how /usr/local/etc/rc.d/bandwidthd.sh is getting generated on boot.

                          Help?!?!

                          Thanks very much!

                          1 Reply Last reply Reply Quote 0
                          • C
                            charliem
                            last edited by

                            Take a look at /usr/local/pkg/bandwidthd.inc; it writes both bandwidthd.sh and bandwidthd.conf

                            1 Reply Last reply Reply Quote 0
                            • P
                              phil.davis
                              last edited by

                              AFAIK it is normal to have 4 bandwidthd processes:

                              ps aux | grep bandwidthd
root       41074  0.0  2.4 15748  5576  -  S     9:41PM  0:00.02 /var/bandwidthd/bandwidthd
root       41237  0.0  2.4 15748  5588  -  S     9:41PM  0:00.01 /var/bandwidthd/bandwidthd
root       41425  0.0  2.4 15748  5576  -  S     9:41PM  0:00.01 /var/bandwidthd/bandwidthd
root       41449  0.0  2.4 15748  5576  -  S     9:41PM  0:00.01 /var/bandwidthd/bandwidthd
root       44012  0.0  0.9 10396  1952  1  S+    9:42PM  0:00.01 grep bandwidthd

                              I think they are related to the recording of daily, weekly, monthly and yearly data/graphs. Each updates data/graphs at different intervals.

                              As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                              If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                              1 Reply Last reply Reply Quote 0
                              • arrmoA
                                arrmo
                                last edited by

                                Hmmm … at least when logging to an external database (PostgreSQL) this causes problems -> I have confirmed multiple entries for the same points in time, and the daily totals in PostgreSQL are 2x what they should be (due to 2 processes running).

                                Thoughts?

                                Thanks!

                                1 Reply Last reply Reply Quote 0
                                • arrmoA
                                  arrmo
                                  last edited by

                                  Could it be this is why we're seeing different results (working / not working)? I think you're letting bandwidthd generate "local" info, but I'm logging to an external database? Just thinking out loud, trying to figure it out.

                                  It is also interesting that the path to your bandwidth process is different - this looks to be processing the data (as it's inside var, right?), but mine is the rc.d service / daemon? I'm just trying to stop more than one of those existing, as I am getting double entries in the database (not a good thing).

                                  Thoughts?

                                  Thanks very much!

                                  1 Reply Last reply Reply Quote 0
                                  • C
                                    charliem
                                    last edited by

                                    Hmm, I have 8 running:

                                    [2.2-RC][root@pfsense.localdomain]/root: ps axfw | grep bandwidthd
                                    93615  -  S        0:05.36 /usr/pbi/bandwidthd-amd64/local/bandwidthd/bandwidthd
                                    93674  -  S        0:04.71 /usr/pbi/bandwidthd-amd64/local/bandwidthd/bandwidthd
                                    93823  -  S        0:04.30 /usr/pbi/bandwidthd-amd64/local/bandwidthd/bandwidthd
                                    94051  -  S        0:04.26 /usr/pbi/bandwidthd-amd64/local/bandwidthd/bandwidthd
                                    94636  -  S        0:05.40 /usr/pbi/bandwidthd-amd64/local/bandwidthd/bandwidthd
                                    94844  -  S        0:04.75 /usr/pbi/bandwidthd-amd64/local/bandwidthd/bandwidthd
                                    95011  -  S        0:04.31 /usr/pbi/bandwidthd-amd64/local/bandwidthd/bandwidthd
                                    95137  -  S        0:04.26 /usr/pbi/bandwidthd-amd64/local/bandwidthd/bandwidthd

                                    Mine is a full 64bit install, with both "generate CDF" and "recover CDF" enabled, but no PostgreSQL logging enabled.  Bandwidthd runs without issues for me for the past few months, but I haven't tried to reconcile traffic reported by bandwidthd to that reported by the rrd graphs in pfSense.  Bandwidthd would be more helpful for me if it could track IPv6 traffic, so I don't use it much.

                                    The nano and full pfSense installs are treated differently by bandwidthd: check /usr/local/pkg/bandwidthd.inc starting around line 302.  The nano config for the $rc['start'] stanza runs from lines 315 to 348, while the stanza for full install is lines 351-353.  So, I think your different command lines are expected (maybe not bug-free :) but expected).

                                    1 Reply Last reply Reply Quote 0
                                    • arrmoA
                                      arrmo
                                      last edited by

                                      Thanks for the awesome pointer! That does help. I admit, I'm not sure how these packages and files fit together - stupidity on my part!

                                      I modified /usr/local/pkg/bandwidthd.inc (locally), and I now avoid the double processes … so one of my problems is resolved. But this also helped me to see the conditions to cause php-fpm to die - more below,

                                      If I go in to /usr/local/etc/rc.d, I can start and stop bandwidthd (and with my change, I only get one copy of the process now). But I also found the conditions to cause php-fpm to die. If I do a Save from the GUI under bandwidthd (which updates /usr/local/etc/rc.d/bandwidth.sh!), then after this if I run bandwidthd.sh, telling it to stop -> php-fpm dies. If I restart php-fpm (manually) ... I can start or stop bandwidth as much as I want, php-fpm never dies again. Only after another Save (and regeneration of bandwidth.sh), then stopping bandwidthd (the first time) kills php-fpm. I also tried this by just manually stopping bandwidthd, by executing /usr/bin/killall bandwidthd ... and this definitely kills php-fpm. If I restart php-fpm, I can't kill php-fpm again (with starts or stops of bandwidthd) ... until I do a Save from the GUI again, then stopping bandwidthd kills php-fpm.

                                      Does this make sense? It seems odd to me, but it is very repeatable.

                                      Thoughts?

                                      Thanks again for the help!

                                      1 Reply Last reply Reply Quote 0
                                      • arrmoA
                                        arrmo
                                        last edited by

                                        BTW (and here comes my stupid, uneducated question … :() - how can doing a killall to bandwidthd kill other processes (php-fpm, but also ntopng)? It really does seem to kill them - but I can't understand why. Figuring this out really is the root cause.

                                        Thanks!!!

                                        1 Reply Last reply Reply Quote 0
                                        • P
                                          phil.davis
                                          last edited by

                                          My home system had 8 bandwidthd processes, for some unknown reason - I guess this is one of your problems with it starting twice under some conditions.
                                          I did the killall command by hand from the command line to see if that would also break php-fpm, and put "-v" so it would tell me what it thinks it killed:

                                          [2.2-RC][root@testoffice-rt-01.xxx]/usr/local/etc/rc.d: ps aux | grep bandwidthd
root    17460   0.0  2.7 15748  6072  -  S     8:29AM    0:00.45 /var/bandwidthd/bandwidthd
root    17871   0.0  2.6 15748  6004  -  S     8:29AM    0:00.33 /var/bandwidthd/bandwidthd
root    18178   0.0  2.5 15748  5804  -  S     8:29AM    0:00.10 /var/bandwidthd/bandwidthd
root    18334   0.0  2.5 15748  5808  -  S     8:29AM    0:00.05 /var/bandwidthd/bandwidthd
root    18587   0.0  2.7 15748  6072  -  S     8:29AM    0:00.45 /var/bandwidthd/bandwidthd
root    18876   0.0  2.6 15748  5988  -  S     8:29AM    0:00.33 /var/bandwidthd/bandwidthd
root    18962   0.0  2.5 15748  5804  -  S     8:29AM    0:00.10 /var/bandwidthd/bandwidthd
root    19024   0.0  2.5 15748  5808  -  S     8:29AM    0:00.06 /var/bandwidthd/bandwidthd
root    77011   0.0  0.9 10396  1960  0  S+    8:48AM    0:00.01 grep bandwidthd
[2.2-RC][root@testoffice-rt-01.xxx]/usr/local/etc/rc.d: /usr/bin/killall -v bandwidthd
kill -TERM 19024
kill -TERM 18962
kill -TERM 18876
kill -TERM 18587
kill -TERM 18334
kill -TERM 18178
kill -TERM 17871
kill -TERM 17460

                                          All worked as expected, and my php-fpm and webGUI still works.
                                          Then I did a few save on the Bandwidthd webGUI page. No problem there either, 4 old processes go away, 4 new ones start.
                                          This system is using local bandwidthd data. I will try in a while with "Log data to a PostgreSQL database" option.

                                          As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                                          If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                                          1 Reply Last reply Reply Quote 0
                                          • P
                                            phil.davis
                                            last edited by

                                            (which updates /usr/local/etc/rc.d/bandwidth.sh!)

                                            Various scripts an conf files in pfSense are generated from the GUI and startup code, like this one. Once you discover exactly what needs to be changed in the script, then we can change the PHP code to generate the script correctly.

                                            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                                            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.