#16 If enabled logs recovery ...

open
nobody
None
5
2004-03-19
2004-03-19
Anonymous
No

if enabled logs recovery after restarting bandwidthd , no
graphic's output's . Top show's bandwidthd running and
etating many resources . If erase log's or disabel logs
recovery in band***.conf all running ok .

Btw. my system is freebsd 4.7 stable , Celeron 300 cpu ,
128 RAM

Discussion

  • Logged In: NO

    same issue on FreeBSD 4.8-p17 stable.
    truss gives "error: File too large"
    tried removing all but a few lines in each log and still had
    the same issue.
    Also, HUPing only seems to rotate log.cdf and not log[1-4].cdf

     
  • David R Hinkle
    David R Hinkle
    2004-04-09

    Logged In: YES
    user_id=863707

    Reprocessing of the text logs is very cpu intensive and can
    take quite some time. If you let it run long enough it should
    finish and start graphing for you.

    What is truss also, btw? And yes, hupping only rotates the
    first log. Rotating the other logs actually becomes non trivial,
    because I end up rotating out data I need to reproduce the
    graphs, especially on the monthly and yearly versions.

     
  • Logged In: NO

    truss is the BSD version of strace which follows the system
    calls a process is making.
    The system I am running has an AMD 1900XP. The first time I
    ran into this problem I let it run for almost 2 days. Just
    how cpu intensive is this?
    Also, even when I removed every line but one from the logs
    the processes would just sit and spin (after an hour or so I
    just killed them and zeroed ot the logs). Could be a BSD
    specific issue.

     
  • Eli K. Breen
    Eli K. Breen
    2004-06-15

    Logged In: YES
    user_id=392434

    As this guy says, problems reading the log files.

    If I enable logging, the logs MUST be removed in order to
    restart bandwidthd. Leaving this running over night managed
    to send a p3-600 w/512MB to an average load of 17.0.

    The last message returned to the console is:
    root@foo# Recovering logs...
    Recovering from log.cdf...
    Recovering logs...
    Seeking to end of data...
    Recovering from log2.cdf...
    Seeking to end of data...
    Seeking backwards...
    Seeking backwards...
    Recovering logs...
    Recovering from log3.cdf...
    Recovering logs...
    Seeking to end of data...
    Recovering from log4.cdf...
    Seeking backwards...
    Seeking to end of data...
    Seeking backwards...

    trussing the bandwidthd processes returns infinite
    occurrences of:

    read(0x4,0x80ed000,0x4000) ERR#27
    'File too large'

    File size is quite small though.

    root@foo# ls -lh
    total 9936
    -rw-r--r-- 1 root wheel 5M Jun 7 15:41 log.cdf
    -rw-r--r-- 1 root wheel 2M Jun 9 23:42 log2.cdf
    -rw-r--r-- 1 root wheel 722K Jun 9 23:37 log3.cdf
    -rw-r--r-- 1 root wheel 239K Jun 9 16:05 log4.cdf

    This is on FreeBSD murdock.sectornotfound.com 4.9-RELEASE-p1
    FreeBSD 4.9-RELEASE-p1 #2: Tue Jan 27 00:19:51 PST 2004

     
  • Lewis
    Lewis
    2004-10-18

    Logged In: YES
    user_id=1037274

    I am running FreeBSD 4.x as well and have encountered this
    same problem. Is there going to be a fix for this or is there
    anything I can do to work around this issue?
    Thanks,
    Lewis

     
  • Logged In: NO

    Unfortunatly I cannot work on this bug because I do not have
    a BSD box to investigate the problem with. I will see what
    I can do to get ahold of one.

     
  • David R Hinkle
    David R Hinkle
    2005-01-02

    Logged In: YES
    user_id=863707

    Last message was posted by me

     
  • Lewis
    Lewis
    2005-01-02

    Logged In: YES
    user_id=1037274

    Hi Drachs,
    I would be willing to help with this. Is there anything specific
    that I can do to help?
    Thanks,
    Lewis

     
  • David R Hinkle
    David R Hinkle
    2005-01-12

    Logged In: YES
    user_id=863707

    New release is out, please try it and let me know if problem
    still exists.

     
  • Matt
    Matt
    2005-01-14

    Logged In: YES
    user_id=1127075

    Problem still exists in the 2.01 release version on FreeBSD
    4.10.

     
  • David R Hinkle
    David R Hinkle
    2005-01-16

    Logged In: YES
    user_id=863707

    In order to work on this I need a freebsd box that exhibits
    the problem that I can log in as root on. If you can give
    me root on such a box please e-mail me the details at
    drachs@gmail.com . Otherwise I will try to reproduce the
    problem on the SF compile farm, but I don't have the right
    version of BSD or root access there.

     
  • Logged In: NO

    I have tracked this problem down and corrected it in CVS.
    Apparently fseek on FreeBSD does not return -1 on error as
    it does on other platforms. An bug that caused bandwidthd
    to always fseek past the beginning of the log file was
    handled gracefully on other platforms but went undetected
    under FreeBSD. I have corrected both issues. Please
    confirm so I can close this bug report.

    Public CVS is delayed by several hours, wait until you see
    the tag "Log recover under BSD should now work" on
    bandwidthd.c in the cvs browser, Before you try. (Not
    "Fixeda bug that may have been cuasing bandwdithd to enter
    and endless loop on... ")

    Or just try it tommorow, should be updated by then. If this
    fixes the bug I will roll bandwidthd 2.0.2.

    Also please note that you will have to specify the path to
    your log files and htdocs directory in the bandwidthd.conf
    file now. (Or move them to the new default locations
    ${prefix}/var/bandwidthd for logs and
    ${prefix}/var/bandwidthd/htdocs for htdocs). The default
    locations can also now be changes with configure.

     
  • David R Hinkle
    David R Hinkle
    2005-01-17

    Logged In: YES
    user_id=863707

    Last poster was me

     
  • Matt
    Matt
    2005-01-18

    Logged In: YES
    user_id=1127075

    drachs,

    I took a look at the diff for the bandwidthd.c file in the CVS
    version, and then compared that with the copy I have locally.
    Here's what I saw,

    if (fseek(cdf, -IP_NUM*75*
    (config.range/config.interval)/20,SEEK_CUR))

    Would this be the problem? I should think that this line would
    have the comparison to -1, right? At any rate, I modified
    that line to look more like the version in CVS. Here's what I'm
    using now:

    if (fseek(cdf, -IP_NUM*75*
    (config.range/config.interval)/20,SEEK_CUR)== -1 || ferror
    (cdf))

    I've given it a couple of HUP's and restarted, which used to
    make it go insanely wild. It seems to be working so far. I'll
    keep an eye on it and see what develops.

    Let me know if you have any thoughts on this...

    Thanks,

    Matt.

     
  • David R Hinkle
    David R Hinkle
    2005-01-18

    Logged In: YES
    user_id=863707

    That -1 is a problem, the ferror call solves another
    problem, and you also need to change the constants add the
    clearerr call to test the fix. The code should read like this:
    if (fseek(cdf, -512*1024,SEEK_CUR) == -1 ||
    ferror(cdf))
    { // fseek returned error, just
    seek to beginning { // fseek
    returned error, just seek to beginning
    clearerr(cdf);
    fseek(cdf, 0, SEEK_SET);
    fseek(cdf, 0, SEEK_SET);
    return;
    return;
    } }

    Note the clearerr call, and the -512*1024

     
  • Logged In: NO

    The changes in 1.50 appear to have resolved this issue.
    FreeBSD 4.11-RELEASE and 4.8-RELEASE

     
  • Logged In: NO

    running FreeBSD 4.11 here and the bug does appear to be
    fixed! A late thank you!!