Bandwidthd problem

[kalu]

Hello every one

I have the latest pfsense build installed:
–--------------------
2.1-DEVELOPMENT (i386)
built on Wed May 2 08:30:27 EDT 2012
FreeBSD 8.3-RELEASE

installed the latest bandwidthd
–-----------------------
"bandwidthd 2.0.1.3"

and it always shows me Please start bandwidthd to populate this directory.
I searched in this forum and was not able to find a proper solution
Thanks
kalu

[kalu]

any guidelines, suggestions ?
i am still unable to make it work.
it's still saying :

Please start bandwidthd to populate this directory.

[pathia]

I'm getting this as well.  I get it in 2.0.1 as well, fresh builds of 2.1, tried 5-6 of them.  Completely wiping the drive and starting over, it does the above right from the get go.  System logs show the below over and over.  It does the same thing if I manually remove and reinstall.  Any ideas?

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'
php: /status_services.php: The command '/usr/local/etc/rc.d/bandwidthd.sh stop' returned exit code '1', the output was 'No matching processes were found'

[heper]

There seems to be an issue with the bandwidthd package:
it has all the missing libs installed at```
/usr/pbi/bandwidthd-i386/lib/

but for some reason it does not want to use that path. this is probably an easy fix for someone who knows where to look. I didn't and just symlinked the libraries required to /usr/local/lib

[2.1-BETA0][root@pfsense.vbees.lan]/root(1): /usr/local/etc/rc.d/bandwidthd.sh start
/libexec/ld-elf.so.1: Shared object "libpq.so.5" not found, required by "bandwidthd"

[2.1-BETA0][root@pfsense.vbees.lan]/root(23): ln -s /usr/pbi/bandwidthd-i386/lib/libpq.so.5  /usr/local/lib/

[2.1-BETA0][root@pfsense.vbees.lan]/root(24): /usr/local/etc/rc.d/bandwidthd.sh start                                       
/libexec/ld-elf.so.1: Shared object "libgd.so.4" not found, required by "bandwidthd"

[2.1-BETA0][root@pfsense.vbees.lan]/root(25): ln -s /usr/pbi/bandwidthd-i386/lib/libgd.so.4  /usr/local/lib/

[2.1-BETA0][root@pfsense.vbees.lan]/root(26): /usr/local/etc/rc.d/bandwidthd.sh start                                       
/libexec/ld-elf.so.1: Shared object "libpng15.so.15" not found, required by "bandwidthd"

[2.1-BETA0][root@pfsense.vbees.lan]/root(27): ln -s /usr/pbi/bandwidthd-i386/lib/libpng15.so.15 /usr/local/lib/
[2.1-BETA0][root@pfsense.vbees.lan]/root(28): /usr/local/etc/rc.d/bandwidthd.sh start

<<–->> NO ERRORS  <<--->>

[2.1-BETA0][root@pfsense.vbees.lan]/root(30): killall bandwidthd

Goto WebGui –> services ---> start BandwidthD

[2.1-BETA0][root@pfsense.vbees.lan]/root(33): ps aux | grep bandwidthd
root    1086  0.0  1.7  7816  3836  ??  S    12:35AM  0:00.02 /usr/local/bandwidthd/bandwidthd /usr/pbi/bandwidthd-i386/bandwidthd/etc/bandwidthd.conf
root    1121  0.0  1.7  7816  3836  ??  S    12:35AM  0:00.02 /usr/local/bandwidthd/bandwidthd /usr/pbi/bandwidthd-i386/bandwidthd/etc/bandwidthd.conf
root    1267  0.0  1.6  7816  3776  ??  S    12:35AM  0:00.03 /usr/local/bandwidthd/bandwidthd /usr/pbi/bandwidthd-i386/bandwidthd/etc/bandwidthd.conf
root    1303  0.0  1.6  7816  3776  ??  S    12:35AM  0:00.02 /usr/local/bandwidthd/bandwidthd /usr/pbi/bandwidthd-i386/bandwidthd/etc/bandwidthd.conf
root  21601  0.0  0.3  1860  796  0  R+  12:50AM  0:00.00 grep bandwidthd

[jimp]

You must be on a recent snapshot for PBIs to work, at the very least, you must be on June 25th or later.

The behavior you're seeing is what would happen on an older build.

[phil.davis]

I upgraded to the latest snapshot:
2.1-BETA0 (i386)
built on Tue Jul 3 17:55:06 EDT 2012
FreeBSD 8.3-RELEASE-p3

Reinstalled bandwidthd and it has started first time by itself, no tweaking needed:

7784  ??  S      0:02.02 /usr/local/bandwidthd/bandwidthd /usr/pbi/bandwidthd-i386/bandwidthd/etc/bandwidthd.conf
58029  ??  S      0:02.05 /usr/local/bandwidthd/bandwidthd /usr/pbi/bandwidthd-i386/bandwidthd/etc/bandwidthd.conf
58030  ??  S      0:02.47 /usr/local/bandwidthd/bandwidthd /usr/pbi/bandwidthd-i386/bandwidthd/etc/bandwidthd.conf
58192  ??  S      0:02.47 /usr/local/bandwidthd/bandwidthd /usr/pbi/bandwidthd-i386/bandwidthd/etc/bandwidthd.conf

In a while I will see if some data is recorded and reports are able to be displayed. But so far it looks good.

[phil.davis]

I spoke too soon. I looked harder at my settings and output_cdf and draw graphs were off. So I guess it was idling along in the background but not putting data anywhere. At least there are no lib errors starting the program.

Jul  4 11:41:53 bandwidthd: Cannot open htdocs/index.html for writing

I am on nanobsd and it wants to write its graph files to:
/usr/pbi/bandwidthd-i386/bandwidthd/htdocs
But that is mounted read-only.
I guess the version for 2.0, before PBIs came along, wrote the graph files somewhere in "/var" and had a mechanism for every now and then saving stuff to the CF card, or maybe the bandwidthd history was simply thrown away when the system rebooted. I have forgotten what it used to do and don't have a 2.0.1 system to try it.
It might all work fine on a non-nanobsd system, where /usr is in a rw file system.
Just for fun, I did "mount -rw /" then kicked off bandwidthd. It runs and writes stuff to htdocs. But the GUI doesn't see the graphs. I suppose the GUI is looking somewhere else for the various graph files. Actually, the graphs did appear after a while, and there is a link from /usr/local/www/bandwidthd to the htdocs dir.
So, it needs a bit of tweaking, at least for nanobsd. If someone can specify how it is intended to be, then I am happy to change and/or test some code.

[jimp]

Easiest way around that is to probably mkdir -p /var/bandwidthd/htdocs during the install process and then make the directory inside the PBI dir a symlink to that.

[TommyTheKid]

For reference, I can tell you that on my 2.0.1 nanobsd box, it writes to /usr/local/bandwidthd/htdocs, so it must not be read-only. It should, however, be read-only because I have destroyed 2 CompactFlash modules now. (oops) I thought the first time it was maybe a fluke, but I am sure it was bandwidthd this time.

Maybe, would it be possible to modify the package to always write its data to /var/local/bandwidthd (or something similar)… and then in a future rev, maybe it could have something similar to RRD where it can periodically (hourly? every x hours, whatever) save the data to CF. ??

~tommy

[Criggie]

@TommyTheKid:

For reference, I can tell you that on my 2.0.1 nanobsd box, it writes to /usr/local/bandwidthd/htdocs, so it must not be read-only.

Same problem here - Alix 2 with
2.1-BETA0 (i386) built on Sat Sep 15 16:38:19 EDT 2012 FreeBSD 8.3-RELEASE-p4

Syslog shows clearly
Sep 23 17:43:10 pfsense2 bandwidthd: Monitoring subnet 10.28.0.0 with netmask 10.28.0.0
Sep 23 17:43:10 pfsense2 bandwidthd: Cannot open htdocs/index.html for writing

#  touch /usr/pbi/bandwidthd-i386/bandwidthd/htdocs/index.php
touch: /usr/pbi/bandwidthd-i386/bandwidthd/htdocs/index.php: Read-only file system

[generious]

@Criggie:

@TommyTheKid:

For reference, I can tell you that on my 2.0.1 nanobsd box, it writes to /usr/local/bandwidthd/htdocs, so it must not be read-only.

Same problem here - Alix 2 with
2.1-BETA0 (i386) built on Sat Sep 15 16:38:19 EDT 2012 FreeBSD 8.3-RELEASE-p4

Syslog shows clearly
Sep 23 17:43:10 pfsense2 bandwidthd: Monitoring subnet 10.28.0.0 with netmask 10.28.0.0
Sep 23 17:43:10 pfsense2 bandwidthd: Cannot open htdocs/index.html for writing

touch /usr/pbi/bandwidthd-i386/bandwidthd/htdocs/index.php

touch: /usr/pbi/bandwidthd-i386/bandwidthd/htdocs/index.php: Read-only file system

Just did the upgrade from 2.0.1

And bandwidth is failing to start errors below
This is another nano install on a CF card in a watchguard, keep in mind this has been working flawless for the past 11months not a single issue and it has been rebooted once in this time.

Dec 6 08:22:22	bandwidthd: Cannot open htdocs/index.html for writing
Dec 6 08:22:22	bandwidthd: Cannot open htdocs/index.html for writing
Dec 6 08:22:22	bandwidthd: Monitoring subnet 10.0.0.0 with netmask 10.0.0.0
Dec 6 08:22:22	bandwidthd: Monitoring subnet 10.0.0.0 with netmask 10.0.0.0
Dec 6 08:22:12	bandwidthd: Cannot open htdocs/index.html for writing
Dec 6 08:22:12	bandwidthd: Cannot open htdocs/index.html for writing
Dec 6 08:22:12	bandwidthd: Monitoring subnet 10.0.0.0 with netmask 10.0.0.0
Dec 6 08:22:12	bandwidthd: Monitoring subnet 10.0.0.0 with netmask 10.0.0.0

[wallabybob]

The quoted netmasks (10.0.0.0.0 and 10.28.0.0) are "unusual". Shouldn't they be 255.0.0.0 or the like?

[phil.davis]

I wanted to see why bandwidthd was reported as working on 2.0.1 nanobsd, so I loaded a clean 2.0.1 on a CF card and stuck it in an Alix 2D13. Directly after installing bandwidthd 2.0.1.3 from the Package Manager the CF card is left mounted RW. So bandwidthd runs, happily scribbling on the CF card at regular intervals until the next reboot.
After a reboot, the CF card is correctly mounted readonly. bandwidthd can't scribble on the CF card. The system log regularly reports this:

Dec 9 18:12:25 	kernel: pid 20118 (bandwidthd), uid 0: exited on signal 11
Dec 9 18:15:43 	kernel: pid 15441 (bandwidthd), uid 0: exited on signal 11
Dec 9 18:15:46 	kernel: pid 31625 (bandwidthd), uid 0: exited on signal 11
Dec 9 18:19:09 	kernel: pid 25051 (bandwidthd), uid 0: exited on signal 11

So 2.0.1 nanobsd systems that have bandwidthd working must have one of:
a) Never been rebooted since installing the package; or
b) An old version of the bandwidthd package that mounts the CF card RW; or
c) Another package that wrongly mounts the CF card RW  at boot time; or
d) A bit of extra code hacked in by the admin to purposely mount the CF card RW.

Anyway, now I know that this is not a new problem in 2.1 - I had been really struggling to see how it could have been working for 2.0.1 nanobsd users.
Now to fix it…

[wadmutter]

I d like to see a fix as i truly miss Bandwidth D. Is there a fix that a newbie to Linux like me could deploy easily ?

[kalu]

Nope there's not a fix yet.
I'm on
–----
pfsense:
2.1-BETA1 (i386)
built on Thu Dec 27 15:19:47 EST 2012
FreeBSD 8.3-RELEASE-p5

---

Bandwidthd
BETA
2.0.1.3
platform: 1.2.1

still throws error:::: Please start bandwidthd to populate this directory.
:(

[serialdie]

Any updates on this issue? :(

[kalu]

ditto.
Any updates ?

[Krakke]

on install i get this in the syslog
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'

/usr/local/etc/rc.d/bandwidthd.sh start
Syntax Error "syntax error" on line 32

However there is no line 32 in bandwidthd.sh  ???

Running 2.1-BETA1 (amd64)
built on Fri Feb 15 04:33:17 EST 2013
FreeBSD 8.3-RELEASE-p5

[phil.davis]

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'

That is no problem - when it tries to stop/start there will be no existing process running the first time, so that message comes out.

/usr/local/etc/rc.d/bandwidthd.sh start
Syntax Error "syntax error" on line 32

I have nanoBSD systems, and the bandwidthd install now writes a custom bandwidthd.sh for the nanobsd case that puts the bandwidthd output data into /var/bandwidthd - so that the CF card can be left readonly.
I had a look at the code that creates bandwidthd.sh for the other cases and can't see an obvious error.
Please post the bandwidthd package version (latest is 2.0.1.4) and the content of bandwidthd.sh - then I can track down what is going wrong.

[Krakke]

@phil.davis:

Please post the bandwidthd package version (latest is 2.0.1.4) and the content of bandwidthd.sh - then I can track down what is going wrong.

Oh my bad. The last line in the subnet settings text, "The subnet(s) on which bandwidthd will report. (separate with ';' for multiple subnets, e.g. 192.168.1.0/24;10.0.0.0/24)."The ordinary subnet for the selected interface/s is automatically put in the config, do not specify it here."
Well i had, and it gave me that error, now im running bandwithd without problems  ;)

So if anyone get
bandwidthd: Syntax Error "syntax error" on line 32
bandwidthd: Syntax Error "syntax error" on line 33
Check subnet config