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

[Tobias Oetiker]

Hi Sebastian,

Today Sebastian Harl wrote:

> 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.

PNG is the most binary data format supported by rrdtool, so this is
no problem and what's more, the \n is only 'appended' in piping
mode.

do you see another solution ?

> > 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> ;-)

look at the RRDp code, I don't think it looks for \nOK it is happy
with \n

cheers
tobi
>
> Cheers,
> Sebastian
>
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900