RE: RFS: bandwidthd - tracks network utilization per ip and draws graphs.
Hi Eduard!
... and David, which I think might be interested in the "bandwidthd skips
graphing bug" part right below.
Eduard, sorry for not spotting your mail sooner...
I'm not subscribed to debian-mentors and forgot to mention that I want
to be CCed.
For anyone interested in reading Eduards initial mail:
http://lists.debian.org/debian-mentors/2004/07/msg00136.html
The thread started here:
http://lists.debian.org/debian-mentors/2004/07/msg00120.html
To everyone for the future:
Please _always_ CC me when replying to any of my mails
or anything that you think I might be interested in....
Bandwidthd skips graphing bug...
I also triggered this when installing bandwidthd on my workstation
yesterday.... (trying out debconf changes which I finally managed to
get "working").
I haven't done an extensive review of the code but from what I've seen
it could need some cleanups (more then the few ones I've already done).
About "Previouse graphing run not complete... Skipping current run"..
Bandwidthd forks of children for doing the graphing so that no packets
get lost if it takes some time to finish. These children aren't reaped
until the next graphing run... If it's time to graph and there aren't
any children to reap bandwidthd currently thinks the previous run isn't
complete.
Atleast on my workstation yesterday there where no graph childs at
all... just the main 4 processes.... I don't know (yet) how this is
possible but I will look into in really soon.
The only thing I can think of straight up is that the first fork fails
(and checking for fork failures isn't done) and there's no children to
reap creating the infinite loop which never forks any children.
I don't think that fork failure is very likely to happen on my idle
workstation every time I tried restarting bandwidthd so as I said, I'll
have to look closer at it...
Priority: critical
Next issue...
Bandwidthd outputs stuff to stdout.... like "Packet Encoding: Ethernet".
It's on the upstream TODO-list and also one of my highest priorities to
change bandwidthd to behave like a daemon should.... This includes
_not_ "working out of the current directory" as it currently does and
using syslog for any messages.
Closing stdin/stdout/stderr is required before the package can be
moved to the debconf layout I've created.
I've send a couple of minor patches to David Hinkle (upstream) which I'd
like to see merged before I continue with more work though...
(He said he'll do a final review and then merge them but I haven't heard
anything and they haven't shown up in the cvs at sourceforge so I'm
still waiting..)
Priority: high
Moving along....
> Few things that come to my mind...
>
> - write the required config steps into README.Debian
Don't know why I haven't done this yet.... Will do ASAP.
My goal is to (optionally) manage the config file with debconf though,
but as this will not happen until I've finished the "daemon behave
cleanup" I'll document the config steps for now.
Priority: critical
> - move TODO paragrah into debian/TODO file (there are extra handling
> methods for a such file)
I've though about it, but my goal was to not have any unfinished buissness.
I guess that was really naive of me.. Will do this...
Priority: high
> - do not confuse with megabyte (m, MB, 10^6) and mebibyte (M, MiB, 2^10)
I was under the impression that bandwidthd only did bits (not bytes) which
simplifies this issue alot. :)
The TODO-item in my readme is more about when to use upper- and lower-case.
AFAIK this is how it's supposed to be:
Mega and above should be uppercase. Kilo and below should be lowercase.
Bit should be lowercase (and byte uppercase, but since there's only bits...)
Seconds should be lowercase.
But who cares....
Priority: low
Guess I need to go shopping for medium priority issues. ;)
Just started my vacation like 1 hour ago, so these issues will have to wait
a couple of days. I've hopefully made some progress in a week unless
someone else cracks all these nuts before I get a chance.
I'll post a status report to the list later on....
Thanks to everyone who've posted comments so far!
Regards,
Andreas Henriksson
Reply to: