steve- great patch! good contribution (although Gap, Inc. might force you to change the name :P)
do you have any idea how the RRDs got corrupted? -- matt Today, Steven Wagner wrote forth saying... > This patch was made against 2.5.2 - I haven't tested it on the latest CVS > version. > > What you get: > > * gmetad starts passing a timestamp value down to the individual RRD > updating functions. > * If a timestamp isn't provided, it generates one using your platform's > POSIX-compliant time() function. > > This patch may make gmetad unstable, which is why I'm posting it here - I'd > like to see what other people's experiences are with this patch. I've > tested it on my Solaris 9 (yeah, I upgraded...) front-end and it's working > beautifully so far. > > Last week I had all sorts of gmetad stability problems which turned out to > be related to having a number of truncated/corrupted RRD files. gmetad > doesn't currently make allowances for this - if an RRD file exists, it > assumes it's working properly. If it doesn't exist, it tries to create it. > That's it. > > I went through and deleted the truncated files by hand, but a more elegant > solution would clearly be to make gmetad a little more RRD-aware in the > long run. I'm not sure exactly how this contributed to my gmetad crashing > every 40 minutes (perhaps there's some sort of memleak associated with an > RRD*() error condition?), but the problem popped up when I moved RRD > directories and accidentally left some truncated RRDs around, and > disappeared after I removed 'em. > > So stay alert, trust no one, keep your laser handy, et cetera. > >
