Red Hat Bugzilla – Bug 397891
rrdtool eats data on update!
Last modified: 2008-02-05 20:44:22 EST
The rrdtool in fedora 8 is extremely broken. Each "update" invokation eats a
couple of data points instead of adding new ones.
I had cacti running for about an hour (~12 rrdtool invokations), which ate 30
hours worth of data from the rrd files.
I've now downgraded to rrdtool from fedora 7, which is working. I'm just lucky I
spotted this and also had a backup of my rrd files. Others might not be so
fortunate, which is why you should post a fix ASAP.
I've not had the time to look into this, but development of rrdtool has
continued on, and a 1.3-beta2 has been released. I've built this for rawhide and
have it currently building for F8, as it does fix another outstanding F8 bug
w/munin. I'd like to know if the update also remedies this problem. If not, I'll
take it up with upstream.
Slight improvement. beta 2 doesn't seem to be eating any old data, but it isn't
adding any new either. So the problem is still there, just less severe.
As a note, beta 2 does something to the files (a few bytes here and there are
changed). But there are no visible changes changes in the graphs generated from
Also, beta 1 and beta 2 both modify the files without having mtime changing on
the files. Very odd.
There is a problem with the beta1 code that causes updates to fail if the rrd
file is version 1.
rrdtool info file.rrd | grep rrd_version
if the answer is "0001" then you're seeing the same problem I have.
You can work around this by performing a dump and restore which will upgrade the
version to "0003" at which point updates should succeed.
rrdtool dump file.rrd >tmp.xml
rrdtool restore -f tmp.xml file.rrd
That was indeed the case. All of my files were version 1. After an upgrade to
version 3, things seem to be running smoothly.
Excellent, good to know. Would be nice if that upgrade happened automagically, but at least there's a
work-around for people to find if they come searching bugzilla...
(In reply to comment #3)
> Also, beta 1 and beta 2 both modify the files without having mtime changing on
> the files. Very odd.
files updated through mmap not getting their mtime updated is a kernel bug as
reported in :
couldn't find a RH bugzilla entry for that though but it is fixed already upstream