Steven Wagner wrote:
Steven Wagner wrote:
matt massie wrote:
steve's comment about not being able to be set rrd_rootdir in
gmetad.conf
made me review my ./gmetad/conf.c code. i didn't have some of the
functions returning NULL which made dotconf mad. it's all good now.
-matt
Yup, that works.
[yaaaaaaaaay!]
Now to try the new front-end... if all goes well I'll be hackin' on
some proprietary stuff for a while...
Wait a minute!
I noticed my RRDs stopped updating when I switched binaries. Now I get
... THIS! ... when I run with debug on:
RRD_update: rrd->ds_def malloc
save_to_rrd() couldn't parse the XML and data to RRD for [fs]
That's a librrd issue of some kind, because I get it when I invoke
rrdtool directly. So. Not sure what's going on there but I'm hungry
and I'm going to lunch now. :) I will be sure to ask my Double-Double
whether it has any ideas on how to fix this issue.
Additional additional: I've found the problem. It's a library issue -
apparently when I compile rrdtool 1.0.x using my 64-bit gcc 3.0 compiler,
it barfs in this manner when run. For example:
> ./rrdtool dump
/www/gmetad/rrds/Cluster/nameofavalidnode.ourdomain.com/mem_free.rrd
ERROR: rrd->ds_def malloc
I've tried this with 1.0.33, 1.0.37, and 1.0.39.
The version that works is an ELF32 binary, the version that doesn't is
ELF64. That's about the only difference I've found.
So either this is a Solaris issue, a Steve's Funky Install issue (doubtful,
it happens on several machines...), a gcc 3.0-sparcv9 issue (possible...),
or a rrdtool-not-liking-sparcv9 issue...
