postgresql database problem

  • libran

    libran - 2005-03-11

       I have installed bandiwidthd-2.0.1 on fedora core 2.It works fine when stand alone.But when i try to use databse support after configuring all the files correctly,bandwidthd starts fine but it is unable to put any data into the database.In the file /var/log/messages,it shows the following message-

    "wifi-india bandwidthd: Postgresql logging selected but postgresql support is not compiled into binary.  Please check the documentation in README, distributed with this software."

    Here is my bandwidthd.conf file.

    # Bandwidthd.conf
    # Commented out options are here to provide
    # documentation and represent defaults

    # Subnets to collect statistics on.  Traffic that
    # matches none of these subnets will be ignored.
    # Syntax is either IP Subnet Mask or CIDR

    # Device to listen on
    # Bandwidthd listens on the first device it detects
    # by default.  Run "bandwidthd -l" for a list of
    # devices.
    dev "eth1"

    # Options that don't usually get changed

    # An interval is 2.5 minutes, this is how many
    # intervals to skip before doing a graphing run
    #skip_intervals 0

    # Graph cutoff is how many k must be transfered by an
    # ip before we bother to graph it
    #graph_cutoff 1024

    #Put interface in promiscuous mode to score to traffic
    #that may not be routing through the host machine.
    #promiscuous true

    #Log data to cdf file htdocs/log.cdf
    #output_cdf false

    #Read back the cdf file on startup
    recover_cdf false

    #Libpcap format filter string used to control what bandwidthd see's
    #Please always include "ip" in the string to avoid strange problems
    #filter "ip"

    #Draw Graphs - This default to true to graph the traffic bandwidthd is recording
    #Usually set this to false if you only want cdf output or
    #you are using the database output option.  Bandwidthd will use very little
    #ram and cpu if this is set to false.
    graph false

    #Set META REFRESH seconds (default 150, use 0 to disable).
    #meta_refresh 150

    pgsql_connect_string "user = root dbname = bandwidth host = localhost"

    sensor_id ""

    tell me what could be the there any problem with the installed binary or the databse.


    • BaIGuI

      BaIGuI - 2005-03-14

      I think this is a libpq problem. Old libpq version has not PQexecParams function which is used from bandwidthd. Update PostgreSQL to newer version.

      In this case  while you run ./configure is a warnning message:

      "configure: WARNING: libpq exists but is too old... bandwidthd requires support for PQexecParams"

    • papiva

      papiva - 2005-05-12

      I am having the same problem as this user. I installed Bandwidthd on Fedora Core 3. All updates have been applied via YUM. 

      I installed the prerequisite libraries as required. Bandwidthd compiled fine without any errors and works fine until I enable the Postgresql database connection. Then I get the same error " Postgresql logging selected but postgresql support is not compiled into binary. Please check the documentation in README, distributed with this software"

      Specifying Postgres eg. --with-Postgres when running ./configure does not do anything.  I presume it is not neccessary.

      • papiva

        papiva - 2005-05-12

        One last quick question. Has anyone tried successfully using Bandwidthd running on W2K and using pgsql_connect_string  to post data to Postgresql on Linux? This does not appear to be working either.
        Thanks Much

    • gdmort

      gdmort - 2005-05-16

      I have been having the same problem.
      I have discovered, from the following extract of the config.log file, that on my Suse 8.2 system, postgres is not installed at the location where the ./configure script looks for it:

      configure:3078: checking for /usr/local/pgsql/lib
      configure:3093: result: no
      configure:3099: checking for /usr/local/pgsql/include
      configure:3114: result: no

      I believe this is why the binaries are not compiled with postgres support.
      rpm -qa | grep postgres yields:

      and I know the server is up and running and that the bandwidthd tables were successfully created.

      I would like to know, either how to install postgres to the needed location, or how to tell bandwidthd to look in a different location.

      Any help would be greatly appreciated.

    • papiva

      papiva - 2005-06-02

      A followup to gdmort's message. I ran through the steps that you did and recieved the following on my install on Fedore Core 3.

      rpm -qa | grep postgres


      My config.log showed the same results as you did.
      configure:3078: checking for /usr/local/pgsql/lib
      configure:3093: result: no
      configure:3099: checking for /usr/local/pgsql/include
      configure:3114: result: no

      This makes sense due to my install of pgsql is at
      find /usr -name pgsql

      I could not find a /include or /lib directory with this install.
      The first directory listed .so files and the second listed .sql .bki and sample files.

      I suspect because a .deb package was also included with the source code, that Bandwidthd was likely built on a Debian platform. If this is the case, then different Linux distros store applications in different locations. Nothing like a challenge to keep us thinking.

      Is it possible to append a flag to the ./configure script specifying a pgsql location as previously stated above? PHP allows you to include a location parameter like this using " ./configure --with-apxs=/www/bin/apxs"

      Thanks much. Great product by the way. At the moment I am using it with W2K and static pages. Miss the database storage ability though.


    • Luizxx

      Luizxx - 2007-07-27

      I had the same problem compiling a Slackware package...

      I solved the problem making symlinks to the correct location, my pglibdir was /usr/lib and my pgincludedir was /usr/include. After the symlinks I compiled normally (./configure, etc...) and everything is working fine!

      ln -s /usr/lib/ /usr/local/pgsql/lib
      ln -s /usr/include/ /usr/local/pgsql/include

    • James

      James - 2007-12-01

      I found it was easer just to run ./configure, then manually edit the Makefile to give the correct paths (lines 7,8 the ones with *FLAGS* in them)

    • Supacon Fizzix

      Supacon Fizzix - 2008-09-16

      I'm having trouble with bandwidthd telling me that postgresql support isn't compiled into the binary as well.  I am using CentOS 5, and installed postgres stuff with yum, but when I noticed that bandwidthd configure wasn't seeing it, I also manually configured and installed an identical version of postgresql into /usr/local to remedy that problem.  (first I tried manually changing the configure script but the former way seemed more thorough).

      I also tried editing the Makefire as James suggested, but I still get that error about postgresql support not being compiled in.

      I'm not sure what I'm missing...  but I think there's a hint in my config.log, which I will paste part of at the end of this message.

      I'm interested if there are any other ideas as to what might be going on here...  Is the configure script still missing something required for postgresql support?

      configure:2893: checking for gdImageCreate in -lgd
      configure:2920: gcc -o conftest -g -O2  -I/usr/local/include  -L/usr/local/lib conftest.c -lgd  -lpng -lm -lresolv -lnsl  >&5
      configure:2923: $? = 0
      configure:2926: test -s conftest
      configure:2929: $? = 0
      configure:2940: result: yes
      configure:2955: checking for pcap_open_live in -lpcap
      configure:2982: gcc -o conftest -g -O2  -I/usr/local/include  -L/usr/local/lib conftest.c -lpcap  -lgd -lpng -lm -lresolv -lnsl  >&5
      configure:2985: $? = 0
      configure:2988: test -s conftest
      configure:2991: $? = 0
      configure:3002: result: yes
      configure:3078: checking for /usr/local/pgsql/lib
      configure:3093: result: yes
      configure:3099: checking for /usr/local/pgsql/include
      configure:3114: result: yes
      configure:3120: checking for PQconnectdb in -lpq
      configure:3147: gcc -o conftest -g -O2  -I/usr/local/include -I/usr/local/pgsql/include  -L/usr/local/lib -L/usr/local/pgsql/lib conftest.c -lpq  -lpcap -lgd -lpng -lm -lresolv -lnsl
      configure:3150: $? = 0
      configure:3153: test -s conftest
      configure:3156: $? = 0
      configure:3167: result: yes
      configure:3171: checking for PQexecParams in -lpq
      configure:3198: gcc -o conftest -g -O2  -I/usr/local/include -I/usr/local/pgsql/include  -L/usr/local/lib -L/usr/local/pgsql/lib conftest.c -lpq  -lpcap -lgd -lpng -lm -lresolv -lnsl
      configure:3201: $? = 0
      configure:3204: test -s conftest
      configure:3207: $? = 0
      configure:3218: result: yes
      configure:3239: checking for dirent.h that defines DIR
      configure:3259: gcc -c -g -O2  -I/usr/local/include -I/usr/local/pgsql/include conftest.c >&5
      configure:3262: $? = 0
      configure:3265: test -s conftest.o
      configure:3268: $? = 0
      configure:3278: result: yes
      configure:3291: checking for opendir in -ldir
      configure:3318: gcc -o conftest -g -O2  -I/usr/local/include -I/usr/local/pgsql/include  -L/usr/local/lib -L/usr/local/pgsql/lib conftest.c -ldir  -lpq -lpcap -lgd -lpng -lm -lresolv -
      lnsl  >&5
      /usr/bin/ld: cannot find -ldir
      collect2: ld returned 1 exit status
      configure:3321: $? = 1
      configure: failed program was:
      #line 3299 "configure"
      #include "confdefs.h"

      /* Override any gcc2 internal prototype to avoid an error.  */
      #ifdef __cplusplus
      extern "C"
      /* We use char because int might match the return type of a gcc2
         builtin and then its argument prototype would still apply.  */
      char opendir ();
      main ()
      opendir ();
        return 0;
      configure:3338: result: no
      configure:3403: checking for gd.h
      configure:3413: gcc -E  -I/usr/local/include -I/usr/local/pgsql/include conftest.c
      configure:3419: $? = 0
      configure:3438: result: yes
      configure:3505: checking for gdfonts.h
      configure:3515: gcc -E  -I/usr/local/include -I/usr/local/pgsql/include conftest.c

    • Supacon Fizzix

      Supacon Fizzix - 2008-09-16

      I was able to remedy my problem by removing some lines of code - I don't know much about C, so I can't say what the effects of this could be down the road, but essentially this should have forced the postgresql support to be compiled into the binary:

      I removed the lines:
      624 #ifdef HAVE_LIBPQ

      870    syslog(LOG_ERR, "Postgresql logging selected but postgresql support is not compiled into binary.  Please check the documentation in README, distributed with this software.");

      And now things do seem quite a bit happier!

  • Anonymous - 2010-05-05

    Hello, I had the same problem with the database I was also getting the error: "Postgresql logging selected but postgresql support is not compiled into binary", after a lot of searching in installation file bandwidthd.c I change the lines that says:

    #ifdef HAVE_LIBPQ
    #include <libpq-fe.h>


    //#ifdef HAVE_LIBPQ
    #include </usr/include/pgsql/libpq-fe.h>  //where my libpq-fe.h is in my OS, I installed on SuSE 11.0

    After that it worked for me.

  • Mr Tofu

    Mr Tofu - 2011-10-07

    Thanks to this forum I have finally got Bandwidthd logging to my PostgreSQL server.
    I had similar problems, /var/log/messages contained the following:

    "Postgresql logging selected but postgresql support is not compiled into binary. Please check the documentation in README, distributed with this software."

    I had the Postgres-9.1 client installed but  was missing the header file libpq-fe.h which I got hold of by installing postgresql-devel-9.1.rpm using Yum

    # yum install postgresql-devel-9.1

    Then I followed the advice above changing bandwidthd.c, but I did not comment out the ifdef/endif as follows:

    #ifdef HAVE_LIBPQ
    #include </usr/pgsql-9.1/include/libpq-fe.h> //CentOS 5.6 specific  location

    I recompiled bandwidthd but still had the same problem.
    While running ./configure I noticed that the two PostgreSQL tests failed:

    checking for /usr/local/pgsql/lib… no
    checking for /usr/local/pgsql/include… No

    These folders did not so I created symbolic links to where these folders actually were on my CentOS 5.6 system:

    # ln -s /usr/pgsql-9.1/include /usr/local/pgsql/include
    # ln -s /usr/pgsql-9.1/lib /usr/local/pgsql/lib

    I recompiled bandwidthd and ./configure passed those two tests:

    checking for /usr/local/pgsql/lib… yes
    checking for /usr/local/pgsql/include… Yes

    I ran bandwidthd and after a couple of minutes it started logging to my remote Postgres database server.

    The default phphtdocs set up may allow your  config.conf file containing your database details to be served by your web server so I added the following directive to my Apache httpd.conf to prevent it serving any *.conf files and restarted Apache:

    <Files ~ "\.conf$">
    Order allow,deny
    Deny from all

    Now bandwidthd is working really well.


Log in to post a comment.