Menu
▾
▴
#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
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
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.
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
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.
Logged In: YES
user_id=863707
Last message was posted by me
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
Logged In: YES
user_id=863707
New release is out, please try it and let me know if problem
still exists.
Logged In: YES
user_id=1127075
Problem still exists in the 2.01 release version on FreeBSD
4.10.
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.
Logged In: YES
user_id=863707
Last poster was me
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.
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: YES
user_id=863707
SF mangled the code, see this:
http://cvs.sourceforge.net/viewcvs.py/bandwidthd/bandwidthd/bandwidthd.c?r1=1.48&r2=1.50
There are 4 changes in the bottom snipper. Seek offset is
changed to -512*1024, ferror(cdf) is added, clearerr(cdf)
is added, and the test for -1 instead of null.
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!!