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

    Bandwithd not working after update

    Scheduled Pinned Locked Moved pfSense Packages
    11 Posts 8 Posters 3.0k 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.
    • I
      individual-it
      last edited by

      I have the same problem, libraries are missing.

      ldd /usr/pbi/bandwidthd-i386/bandwidthd/bandwidthd
/usr/pbi/bandwidthd-i386/bandwidthd/bandwidthd:
	libpq.so.5 => not found (0x0)
	libpcap.so.1 => not found (0x0)
	libgd.so.4 => not found (0x0)
	libpng15.so.15 => /usr/local/lib/libpng15.so.15 (0x2809a000)
	libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x280c5000)
	libm.so.5 => /lib/libm.so.5 (0x281bd000)
	libc.so.7 => /lib/libc.so.7 (0x281d7000)
	libz.so.5 => /lib/libz.so.5 (0x282e2000)

      header files are included in /usr/pbi/bandwidthd-i386/include but cannot find the compiled libs

      1 Reply Last reply Reply Quote 0
      • 3
        3n1gm4
        last edited by

        I am having the same problem after updating from 2.0.3 to 2.1.  I have removed and re-installed the package.  I have removed the packaged, rebooted the firewall, then installed bandwidthd again, then rebooted again.  This problem is with Bandwidthd 2.0.1_5 pkg v.0.2 as well.

        I have tried to disable and enable bandiwdthd.

        Error 1, getting the wrong netmask:

        Nov 20 22:57:20 bandwidthd: Monitoring subnet 172.20.15.0 with netmask 172.20.15.0
        Nov 20 22:57:20 bandwidthd: Monitoring subnet 172.20.10.0 with netmask 172.20.10.0
        Nov 20 22:57:20 bandwidthd: Monitoring subnet 172.20.1.0 with netmask 172.20.1.0

        Error 2,  no matching processes:

        Nov 20 22:57:18 php: /pkg_edit.php: The command '/usr/local/etc/rc.d/bandwidthd.sh stop' returned exit code '1', the output was 'No matching processes were found'

        When opening bandwidthd, it gives me this error:

        Please start bandwidthd to populate this directory.

        I have this working in many clean install 2.1 environments.  The 2.0.3 to 2.1 upgrade just broke it somehow.

        Please help!

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

          @individual-it - how did we fix that missing libraries thing on the system with that problem? and did we work out what was the cause?
          I just tried a bandwidthd package install on a fresh 2.1-RELEASE system and it worked fine.

          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
          • W
            Weiyentan
            last edited by

            I have the same problem after I upgraded. Is there any resolution to this?

            1 Reply Last reply Reply Quote 0
            • D
              DaveQB
              last edited by

              Running:

              pfSense 2.1
              bandwidthd 2.0.1_5 pkg v.0.3

              My solution was.

              [root@pfsense /usr/local/www]# rm bandwidthd
              [root@pfsense /usr/local/www]# ln -s /usr/local/bandwidthd/htdocs/ bandwidthd

              The symlink was originally pointing to /usr/pbi/bandwidthd-i386/bandwidthd/htdocs

              1 Reply Last reply Reply Quote 0
              • G
                generious
                last edited by

                @DaveQB:

                Running:

                pfSense 2.1
                bandwidthd 2.0.1_5 pkg v.0.3

                My solution was.

                [root@pfsense /usr/local/www]# rm bandwidthd
                [root@pfsense /usr/local/www]# ln -s /usr/local/bandwidthd/htdocs/ bandwidthd

                The symlink was originally pointing to /usr/pbi/bandwidthd-i386/bandwidthd/htdocs

                This worked for me, Bandwidthd failed after upgrading pfsense to 2.1.1-RELEASE back working again.

                1 Reply Last reply Reply Quote 0
                • D
                  DaveQB
                  last edited by

                  @generious:

                  This worked for me, Bandwidthd failed after upgrading pfsense to 2.1.1-RELEASE back working again.

                  Good to hear. I don't know how this error slipped into the bandwidthd package.

                  1 Reply Last reply Reply Quote 0
                  • M
                    mattlach
                    last edited by

                    @DaveQB:

                    Running:

                    pfSense 2.1
                    bandwidthd 2.0.1_5 pkg v.0.3

                    My solution was.

                    [root@pfsense /usr/local/www]# rm bandwidthd
                    [root@pfsense /usr/local/www]# ln -s /usr/local/bandwidthd/htdocs/ bandwidthd

                    The symlink was originally pointing to /usr/pbi/bandwidthd-i386/bandwidthd/htdocs

                    Hmm…

                    This did not help for me.

                    It replaced my "Please start bandwidthd to populate this directory." message with a "404 - Not Found" page :(

                    Any suggestions?

                    1 Reply Last reply Reply Quote 0
                    • M
                      mattlach
                      last edited by

                      @mattlach:

                      @DaveQB:

                      Running:

                      pfSense 2.1
                      bandwidthd 2.0.1_5 pkg v.0.3

                      My solution was.

                      [root@pfsense /usr/local/www]# rm bandwidthd
                      [root@pfsense /usr/local/www]# ln -s /usr/local/bandwidthd/htdocs/ bandwidthd

                      The symlink was originally pointing to /usr/pbi/bandwidthd-i386/bandwidthd/htdocs

                      Hmm…

                      This did not help for me.

                      It replaced my "Please start bandwidthd to populate this directory." message with a "404 - Not Found" page :(

                      Any suggestions?

                      Never mind, I was being an idiot.

                      Looks like this was fixed, but I was getting th emessage because I actually DID forget to start bandwidth d.  Then I moved the symlink to the - now - incorrect location.

                      I found the correct one in /usr/pbi/bandwidthd-amd64/bandwidthd/htdocs/, and recreated the symlink and now everything works. :p

                      1 Reply Last reply Reply Quote 0
                      • D
                        DaveQB
                        last edited by

                        @mattlach:

                        @mattlach:

                        @DaveQB:

                        Running:

                        pfSense 2.1
                        bandwidthd 2.0.1_5 pkg v.0.3

                        My solution was.

                        [root@pfsense /usr/local/www]# rm bandwidthd
                        [root@pfsense /usr/local/www]# ln -s /usr/local/bandwidthd/htdocs/ bandwidthd

                        The symlink was originally pointing to /usr/pbi/bandwidthd-i386/bandwidthd/htdocs

                        Hmm…

                        This did not help for me.

                        It replaced my "Please start bandwidthd to populate this directory." message with a "404 - Not Found" page :(

                        Any suggestions?

                        Never mind, I was being an idiot.

                        Looks like this was fixed, but I was getting th emessage because I actually DID forget to start bandwidth d.  Then I moved the symlink to the - now - incorrect location.

                        I found the correct one in /usr/pbi/bandwidthd-amd64/bandwidthd/htdocs/, and recreated the symlink and now everything works. :p

                        Ahh I see. Well I hope I put you on the right track with my post.

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