Given a php script with: $ret = rrd_update("$rrdbasedir/$dec.rrd","N:$rssi:$sq:$sna:$rxoct:$rxpack:$txoct:$txpack"); if ( $ret == 0 ) { $err = rrd_error(); echo "Update error: $err\n"; } When valid values are passed in, an error is generated: Update error: opening 'update': No such file or directory I don't think this is any error in the above code, but something odd with the EPEL-5 rrdtool-php package. Any ideas where this error is coming from or what is causing it?
I seem to recall that I forgot to spin 1.2.27 for epel, and epel is still at 1.2.23 or 1.2.24... Pretty sure the php bits themselves remain unchanged between the two versions, but if you could, try bumping to 1.2.27 and see if it doesn't help...
Just submitted 1.2.27 builds for both EL4 and EL5...
Those packages give me: error: Failed dependencies: php-api = %{php_apiver} is needed by rrdtool-php-1.2.27-1.el5.i386 On trying to install. ;( If I ignore the failed dep (with --nodeps), they generate the same error as the older ones. ;(
(In reply to comment #3) > Those packages give me: > > error: Failed dependencies: > php-api = %{php_apiver} is needed by rrdtool-php-1.2.27-1.el5.i386 > > On trying to install. ;( D'oh. Fixing. > If I ignore the failed dep (with --nodeps), they generate the same error as the > older ones. ;( Damn. I got nothin' right now. We probably need to ping Tobi.
Yeah, I poked around with it some more, and it's in the php bindings for sure. Manually running 'rrdtool update ...' with the same args as the php version of rrd_update works fine. So, somewhere the update is picking up a 'update' file instead of the real one. In rrdtool.c.php: argv[0] = "dummy"; argv[1] = estrdup("update"); argv[2] = estrdup(file->value.str.val); argv[3] = estrdup(opt->value.str.val); So it's passing 'dummy update FILE VALUE', perhaps the args to rrd_update have changed?
Ok, should we talk with upstream about this one? Can you do that? Or would you like me to try and do so? Or do you have any further ideas?
I got nothin', and don't actually use the php bits for anything myself. That. and I've got a fair amount of other things I need to work on this week, so if you could chase this upstream, that would be great. Actually, I really ought to hand this package over to someone else, I don't really use any of the bits period for anything anymore...
Filed an upstream ticket: http://oss.oetiker.ch/rrdtool-trac/ticket/150 Which got closed as invalid, as they don't ship any official php bindings. ;( I also just dropped an email to the mailing list upstream... If you have any ideas, please let me know. ;(
The following patch (From Sean Reifschneider <jafo>) fixes this for me: *** rrdtool-1.2.27/php4/rrdtool.c.old Fri Apr 4 17:43:53 2008 --- rrdtool-1.2.27/php4/rrdtool.c Fri Apr 4 17:44:26 2008 *************** *** 373,379 **** argv[3] = estrdup(opt->value.str.val); optind = 0; opterr = 0; ! if ( rrd_update(3, &argv[1]) != -1 ) { RETVAL_TRUE; } --- 373,379 ---- argv[3] = estrdup(opt->value.str.val); optind = 0; opterr = 0; ! if ( rrd_update(2, &argv[2]) != -1 ) { RETVAL_TRUE; } So, can you apply the above, and we can close this out? Or would you like me to apply it?
Gah... Patched up rawhide... but does this actually impact rawhide, or did I just break rawhide? :) I'll toss it into el5 in a sec.
EL5 and EL4 packages building now