Package: bandwidthd
Version: 2.0.1+cvs20090917-4.1
Severity: normal
When using bandwidthd with the recover-cdf option set to true the log
files will never get correctly read on startup. This is true even if
the CDF files exist and are valid.
The following messages are seen in the logs on startup:
bandwidthd: Finished recovering 0 records
bandwidthd: Failed to parse part of log file. Giving up on the file
This seems to be the same issue as a bug submitted upstream that is a few
years old. (Sourceforge tracker number 2018613.) However, the upstream
project seems rather dead.
The bug is a simple mistake with a pair of fscanf calls. They
expect 7 fields to be parsed when they ask for 8. I've attached a
patch that fixes the problem and I've submitted the same patch to the
upstream tracker.
-- System Information:
Debian Release: 6.0.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- bandwidthd-2.0.1+cvs20090917.orig/bandwidthd.c
+++ bandwidthd-2.0.1+cvs20090917/bandwidthd.c
@@ -1192,10 +1192,10 @@
if (fscanf(cdf, "%llu,%llu,%llu,%llu,%llu,%llu,%llu,%llu,",
&ip->Send.total, &ip->Send.icmp, &ip->Send.udp,
- &ip->Send.tcp, &ip->Send.ftp, &ip->Send.http, &ip->Send.mail,
&ip->Send.p2p) != 7
+ &ip->Send.tcp, &ip->Send.ftp, &ip->Send.http, &ip->Send.mail,
&ip->Send.p2p) != 8
|| fscanf(cdf, "%llu,%llu,%llu,%llu,%llu,%llu,%llu,%llu",
&ip->Receive.total, &ip->Receive.icmp, &ip->Receive.udp,
- &ip->Receive.tcp, &ip->Receive.ftp, &ip->Receive.http,
&ip->Receive.mail, &ip->Receive.p2p) != 7)
+ &ip->Receive.tcp, &ip->Receive.ftp, &ip->Receive.http,
&ip->Receive.mail, &ip->Receive.p2p) != 8)
goto End_RecoverDataFromCdf;
}
