Bug 397891

Summary:	rrdtool eats data on update!
Product:	[Fedora] Fedora	Reporter:	Pierre Ossman <pierre-bugzilla>
Component:	rrdtool	Assignee:	Jarod Wilson <jarod>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	8
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
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:	---	Target Upstream Version:
Embargoed:

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