First, I'd upgrade to the latest version of the major version you're

running, in this case, to 2.5.1. Many many bugs have been fixed. You

should be able to do this without losing anything new, but backups are

always a good idea.

Are these files actually being updated, that is, do you see new graph

data? If so, I'd probably open a ticket

http://dev.zenoss.com/trac/wiki/HowToAddTicket

to at least report the bug/oddity, unless someone else has more info

that I do on this.

--

James Pulver

Information Technology Area Supervisor

LEPP Computer Group

Cornell University

RyanK wrote, On 12/16/2009 6:24 PM:

We have a very basic install of Zenoss that we are using for evaluation purposes. Its running 2.5.0 (on CentOS, installed via the stack installer, if that matters).

 

We have added several machines with the hopes that we can begin to track performance data over time. However, I went to present some of what Zenoss could potentially do for us and found that our RRD files only went back a few weeks, despite being running for several months.

 

After digging, I found entries in zenperfsnmp.log for each RRD file:

 

zenperfsnmp.log.2:2009-11-29 03:22:32,554 WARNING zen.zenperfsnmp: Deleting old RRD file: /usr/local/zenoss/zenoss/perf/Devices/testserver/os/interfaces/MS TCP Loopback interface/ifOutOctets_ifOutOctets.rrd

 

That coincides with when the data was wiped out. Looking at that file produces:

 

1. stat "/usr/local/zenoss/zenoss/perf/Devices/testserver/os/interfaces/MS TCP Loopback interface/ifOutOctets_ifOutOctets.rrd"

  File: `/usr/local/zenoss/zenoss/perf/Devices/testserver/os/interfaces/MS TCP Loopback interface/ifOutOctets_ifOutOctets.rrd'

  Size: 35296           Blocks: 80         IO Block: 4096   regular file

Device: fd00h/64768d    Inode: 6187281     Links: 1

Access: (0644/-rw-rr)  Uid: (  501/  zenoss)   Gid: (  501/  zenoss)

Access: 2009-12-16 17:13:31.000000000 -0600

Modify: 2009-11-29 03:22:33.000000000 -0600

Change: 2009-11-29 03:22:33.000000000 -0600

 

 

so, sure enough.. the modification date of the files are not being updated, so when the cleanup function within zenperfsnmp.py runs, it appears as if these files are not being modified. I tried searching and it appears as if nobody else is having this issue and I'm not really sure what the best way to go about dealing with this is. I would expect that the RRD tool would simply be writing these files and the filesystem (which doesn't have nomtime set) would update the modification date, but perhaps some version of RRD is keeping the files open or something? I've tested that when I edit files they indeed get their modification dates updated so, I'm kinda out of ideas at this point.

 

Just a wild guess... I could easily write a script that will run through and touch all the rrd files to update the modification dates, but that seems to be just a crude workaround that I'd rather avoid if possible.

 

Thanks for the help!

 

>

How about using 'lsof' to determine if a file is being held open by RRDTool and only delete those that are not open?

Something like (untested):

#!/bin/sh

# Find rrd files with modification time older than 60 days

for i in `find $ZENHOME/perf -mtime +60 -name *.rrd` ; do

  if lsof $i > /dev/null; then

    # file is open; could do a touch on it to update the timestamp if that helps the find command's accuracy

  else

    # file isn't open; candidate for deletion

    rm $i

done

Did this just start with 2.5.x?  If so, did anyone think to maybe log a Trac ticket for this?

There must be something that you guys have in common which is causing the timestamps not to be updated.

What distro are each of you running?

What filesystem are you using?

I'm using Ubuntu 8.04 with ext3 and I don't have this issue.  Do you have any custom filesystem settings or anything?  Also, http://oss.oetiker.ch/rrdtool-trac/ticket/193 is patched in the version of RRDTool used in 2.5.1.