[rrd-developers] Bug#251701: fix #182217 breaks librrdp-perl

[Sebastian Harl]

Hi Tobi,

On Tue, Apr 07, 2009 at 07:25:47PM +0200, Tobias Oetiker wrote:
> Today Sebastian Harl wrote:
> > > >
> > > > 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?
> 
> adding a newline after the graph output is quite simple, and I
> imagine it would not immediately break anything ...

Hrm ... I'm not sure if this is a good idea. I don't know if some binary
graphics format might cause problems, if "arbitrary" bytes are appended.
PNG does not seem to care (judging from a quick test) but I wouldn't
implement something like that without being sure about that.

> the RRDp code will NOT work when there is a newline inside the graph
> but this has always been the case ...

... a newline followed by the string "OK" ... </nitpick> ;-)

Cheers,
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/e2f027ca/attachment.bin