[rrd-developers] rrd_graph and flush behavior

[kevin brintnall]

Apologies...  I should have referenced realpath(3) , not (2).

-kb

On Tue, May 25, 2010 at 3:28 PM, kevin brintnall <kbrint at rufus.net> wrote:

> The file names in rrdcached are stored as full paths.  When searching for
> matches, the rrdcached uses strcmp(3).  So, you are right: having two
> different file names will cause this problem.
>
> We chose not to resolve the symbolic links in rrdcached for performance
> reasons; instead, the client is responsible for resolving the files to the
> canonical path.  The rrd client code uses realpath(2) to resolve the path to
> its canonical form.
>
> I don't think there is a resolution in the null mount case..  anybody know?
>
> The symbolic link should work.  Can you verify whether realpath(2) on your
> system reports the correct path in the symlink case?  If realpath(2) is
> right and the client is still not providing the right file name, then there
> is definitely a problem.
>
> -kb
>
>
> On Tue, May 25, 2010 at 1:24 PM, Eduardo Bragatto <eduardo at bragatto.com>wrote:
>
>> Hi everyone,
>>
>> I contacted the rrd-users list with this issue and Mr. Oetiker asked
>> me to send it here.
>>
>> I've started using rrdcached a week ago and everything is working just
>> fine, however I'm having problems to produce updated graphs.
>>
>> Let me first describe my setup a little bit:
>>
>> - All my "rrd update" and "rrd graph" calls are using the parameter "--
>> daemon" to take advantage of rrdcached;
>>
>> - rrdcached is started with these parameters: rrdcached -F -t 16 -s
>> nobody -m 0666 -l unix:/tmp/rrdcached.sock -w 900 -l 127.0.0.1:12345
>>
>> - All my "rrd update" calls, write to files in their real location,
>> while "rrd graph" reads the same RRD files in a different location
>> (either because there's some symlink or null mount in the path).
>>
>> I have reviewed the "-b" option from rrdcached, and I understand
>> symlinks are not allowed on the base directory, however the symlink in
>> my case is not in the base directory. Additionally, I have replaced
>> the symlink with a null mount and the problem persists.
>>
>> The problem I'm seeing, can be illustrated here:
>>
>> with symlink or null mount:
>>
>> FLUSH /usr/local/rrd/myproject/repository/local/switches/myswitch/
>> 10146.rrd
>> 0 Nothing to flush: /usr/local/rrd/myproject/repository/local/switches/
>> myswitch/10146.rrd.
>>
>> real file location:
>>
>> Flush /usr/local/rrd/myproject/rrd/switches/myswitch/10146.rrd
>> 0 Successfully flushed /usr/local/rrd/myproject/rrd/switches/myswitch/
>> 10146.rrd.
>>
>> Where:
>>
>> /usr/local/rrd/myproject/reporsitory/local is a symlink (or null
>> mount) to /usr/local/rrd/myproject/rrd
>>
>> I have the impression "rrdcached" is storing the full path of the RRD
>> files internally, and only accepts a FLUSH command if the path is
>> exactly the same as used in "rrd_update".
>>
>> Can you please confirm if this is the correct behavior?
>>
>> If that's just how rrdcached works, I believe we should update the
>> documentation to highlight the importance of using the exact same path
>> from "rrd_update" when flushing.
>>
>> If that's not desirable, and rrdcached is meant to be able to handle
>> different paths, then I believe there's something wrong with the
>> software's logic somewhere in the code (sorry, I didn't really check
>> the source code).
>>
>> I'm probably going to rewrite my application to use the same path both
>> in rrd_update and rrd_graph, however I think it would be better if the
>> path was not a problem for the flush command (i.e. if a flush command
>> is received and there's a symlinkt in the path, the real location
>> could be calculated in order to find the file that needs to be flushed).
>>
>> Thanks for your attention,
>> Eduardo Bragatto.
>>
>> _______________________________________________
>> rrd-developers mailing list
>> rrd-developers at lists.oetiker.ch
>> https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
>>
>
>
>
> --
> kevin brintnall =~ /kbrint at rufus.net/
>
>


-- 
kevin brintnall =~ /kbrint at rufus.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20100525/920fb317/attachment.htm