[rrd-users] Questions from a new user...

[Mark Seger]

I'm new to rrd and so am trying some very basic things.  I've been able 
to create an rrd database - real easy! and have even been able to write 
data to it using commands like:

rrdtool update collectl.rrd 1184857063:0:100:100:0:7776:7776:0:1926:1926

all works as advertised.  Now I want to get fancy and try using RRDp to 
handle the work because I found for a large number of updates the above 
method is pretty slow and I'm sure (or at least hoping) a lot has to do 
with the starting of the rrdtool image every time.

so I now have a perl script that looks like this, which is right out of 
the man page:

#!/usr/bin/perl -w

use lib "/usr/local/rrdtool-1.2.23/lib/perl/5.8.5";
use RRDp;

RRDp::start "/usr/local/rrdtool-1.2.23/bin/rrdtool";
RRDp::cmd ("update", "collectl.rrd", "1184857053:0:98:98:0:0:0:0:0:0");
$answer=RRDp::read;
print "$$answer\n";

The only thing is I get an initialized variable when I try to print 
$$answer as you can see from the following:

[root at poker rrd]# ./test.pl
Use of uninitialized value in concatenation (.) or string at ./test.pl 
line 9.

If I go into the RRDp.pm and uncomment the print statement at line 162, 
I see it set to a value of OK  which would cause the 'else' clause right 
below it to execute which sees there is no error and so returns 
'$buffer'.  Unfortunately $buffer is not defined and so I'm getting the 
uninit var back in my script.  Or am I missing something?

Here's what it looks like with that print statement uncommented as well 
as a print statement I inserted to print the contents of $buffer:

[root at poker rrd]# ./test.pl
OK u:0.00 s:0.00 r:0.08
Use of uninitialized value in concatenation (.) or string at 
/usr/local/rrdtool-1.2.23/lib/perl/5.8.5/RRDp.pm line 170.
BUFFER:
Use of uninitialized value in concatenation (.) or string at ./test.pl 
line 9.

Closer inspection of the 'read' code suggests that if times are returned 
in the OK string from the call to rrdtool, their values are returned in 
the sys, user and real variables and that $buffer, which is 'undef' at 
this point is returned as the value of the function which is exactly 
what I'm seeing.  It's only when the return from rrdtool doesn't return 
ERROR and it also doesn't return OK with properly formatted time strings 
that $buffer is actually set  to a real value.  So if that's the case, 
how is one to tell if the function succeeded or failed  when you get a 
valid OK with times since it returns 'undef' in both cases?

Next I tried causing an error by trying to rewrite the same data and 
again looking at the code can see when RRDp::read generates an error it 
croaks, but I also found I could set RRDp::error_mode to 'catch' and it 
will simply return the error in the RRDp::error variable.  Only problem 
is it never returns to me!  I put a print statement in the 'read' 
function before the croak test and another in my calling program right 
after the call to 'read' and what I see is:

[root at poker rrd]# ./test.pl
Error!  Mode: catch   <<<< my print did this and verified it indeed saw 
my value of 'croak'

and it hangs.  Has anyone seen this behavior before?  I'm running 
RHEL4/Update4 on an AMD box.

-mark