Bug 397891 - rrdtool eats data on update!
rrdtool eats data on update!
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: rrdtool (Show other bugs)
8
All Linux
urgent Severity urgent
: ---
: ---
Assigned To: Jarod Wilson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-24 11:33 EST by Pierre Ossman
Modified: 2008-02-05 20:44 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-02 08:58:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pierre Ossman 2007-11-24 11:33:40 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.
Comment 1 Jarod Wilson 2007-12-06 14:34:45 EST
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.
Comment 2 Pierre Ossman 2007-12-09 13:09:13 EST
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
them.
Comment 3 Pierre Ossman 2007-12-09 13:11:20 EST
Also, beta 1 and beta 2 both modify the files without having mtime changing on
the files. Very odd.
Comment 4 Martin Poole 2007-12-30 14:29:00 EST
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

Comment 5 Pierre Ossman 2007-12-30 18:02:47 EST
That was indeed the case. All of my files were version 1. After an upgrade to
version 3, things seem to be running smoothly.
Comment 6 Jarod Wilson 2008-01-02 08:58:58 EST
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...
Comment 7 Arenas Belon, Carlo Marcelo 2008-02-05 20:44:22 EST
(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 :

  http://bugzilla.kernel.org/show_bug.cgi?id=2645

couldn't find a RH bugzilla entry for that though but it is fixed already upstream

Note You need to log in before you can comment on or make changes to this bug.