[rrd-developers] fix #182217 breaks librrdp-perl

[Sebastian Harl]

Hi,

On Sat, Dec 20, 2008 at 11:57:14PM +0100, Tobias Oetiker wrote:
> Today Sebastian Harl wrote:
> > (This is a follow-up to Debian bug report #251701 [1]. The text also
> > mentions bug report #182217, which can be found at [2].)
> >
> > [1] http://bugs.debian.org/251701
> > [2] http://bugs.debian.org/182217
> >
> > On Sun, May 30, 2004 at 01:20:18PM +0200, Robert Lindgren wrote:
> > > Package: librrdp-perl
> > > Version: 1.0.46-3
> > > Severity: normal
> > >
> > > The fix for #182217 looks to break librrdp-perl, when running
> > > RRDp::cmd "graph - ......" rrdtool doesn't get the the rest of of the
> > > command and waits forever in:
> > >
> > > robert   25577 21.3  0.6  2268 1036 pts/1    S    13:18   0:00
> > > /usr/bin/rrdtool -
> > > root at zeppelin:/usr/local/nagios/sbin# strace -p 25577
> > > read(0,
> > >
> > > when - is changed to an image everything works ok.
> > >
> > > This is quite bad since it breaks all cgi's trying to make a graph on
> > > the fly.
> >
> > This can be reproduced by using a small script like:
> >
> >   #! /usr/bin/perl
> >
> >   use RRDp;
> >
> >   RRDp::start "/usr/bin/rrdtool";
> >
> >   if (! -e "bts#251701.rrd") {
> >       RRDp::cmd 'create bts#251701.rrd --step 300
> >           DS:ds:GAUGE:600:U:U
> >           RRA:AVERAGE:0.5:1:1200
> >           RRA:MIN:0.5:12:2400
> >           RRA:MAX:0.5:12:2400
> >           RRA:AVERAGE:0.5:12:2400';
> >
> >           RRDp::read;
> >   }
> >
> >   RRDp::cmd 'graph - --imgformat PNG
> >       --end now --start end-3600s --width 400
> >       DEF:ds=bts#251701.rrd:ds:AVERAGE
> >       LINE1:ds#0000FF:ds\l';
> >
> >   my $img = RRDp::read;
> >   # ...
> >
> > By now (rrdtool 1.3), the problem is the following:
> >
> > RRDp::read() expects the output to be terminated by a line matching
> > "^OK(<system information>)?". However, when outputting a PNG, the
> > output is most likely not terminated by a newline, so RRDp::read sits
> > there waiting for that magic line forever.
> >
> > I'm not sure how to properly solve that. We don't get an end-of-file
> > marker at that point, so we cannot simply wait for that. One possible
> > way would be to look for "OK ..." at the _end_ of a line. However, since
> > <system information> is optional, we'd get a "false positive" if the
> > output includes "OK" at the end of _some_ line, which, I suppose, might
> > very well happen e.g. when outputting some binary image data. (Btw.,
> > this is already true for "OK" at the beginning of a line which could be
> > seen as a bug as well.)
> >
> > Another way would be to tune the output of the rrdtool server process
> > and return the status (possibly including the number of bytes in the
> > following output) before printing the output of the command. Obviously,
> > this would require to cache all output. Also, this would break all
> > existing applications that use the rrdtool server.

> the graphv interface outputs the graph in a 'sane' way so that RRDp
> could capture it if it was enhanced accordingly ...

Anybody willing to step up to provide a patch? I'm currently fairly
short of time, so I probably won't get to that anytime soon.

Also, I still think that the behavior of RRDp::cmd('graph - [...]')
should be fixed. Waiting forever is not an acceptable behavior imho.
Imho, falling back to graphv in that case is not an option, since the
output of graph and graphv are different. However, bailing out and
reporting an error should be fine. Any comments on that?

TIA,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20090407/a972404e/attachment.bin