Bug 397891 - rrdtool eats data on update!
Summary: rrdtool eats data on update!
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: rrdtool (Show other bugs)
(Show other bugs)
Version: 8
Hardware: All Linux
urgent
urgent
Target Milestone: ---
Assignee: Jarod Wilson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-11-24 16:33 UTC by Pierre Ossman
Modified: 2008-02-06 01:44 UTC (History)
0 users

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


Attachments (Terms of Use)

Description Pierre Ossman 2007-11-24 16:33:40 UTC
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 19:34:45 UTC
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 18:09:13 UTC
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 18:11:20 UTC
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 19:29:00 UTC
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 23:02:47 UTC
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 13:58:58 UTC
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-06 01:44:22 UTC
(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.