Apologies... I should have referenced realpath(3) , not (2).<br><br>-kb<br><br><div class="gmail_quote">On Tue, May 25, 2010 at 3:28 PM, kevin brintnall <span dir="ltr"><<a href="mailto:kbrint@rufus.net">kbrint@rufus.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">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.<br>
<br>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.<br>
<br>I don't think there is a resolution in the null mount case.. anybody know?<br><br>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.<br>
<br>
-kb<div><div></div><div class="h5"><br><br><div class="gmail_quote">On Tue, May 25, 2010 at 1:24 PM, Eduardo Bragatto <span dir="ltr"><<a href="mailto:eduardo@bragatto.com" target="_blank">eduardo@bragatto.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi everyone,<br>
<br>
I contacted the rrd-users list with this issue and Mr. Oetiker asked<br>
me to send it here.<br>
<br>
I've started using rrdcached a week ago and everything is working just<br>
fine, however I'm having problems to produce updated graphs.<br>
<br>
Let me first describe my setup a little bit:<br>
<br>
- All my "rrd update" and "rrd graph" calls are using the parameter "--<br>
daemon" to take advantage of rrdcached;<br>
<br>
- rrdcached is started with these parameters: rrdcached -F -t 16 -s<br>
nobody -m 0666 -l unix:/tmp/rrdcached.sock -w 900 -l <a href="http://127.0.0.1:12345" target="_blank">127.0.0.1:12345</a><br>
<br>
- All my "rrd update" calls, write to files in their real location,<br>
while "rrd graph" reads the same RRD files in a different location<br>
(either because there's some symlink or null mount in the path).<br>
<br>
I have reviewed the "-b" option from rrdcached, and I understand<br>
symlinks are not allowed on the base directory, however the symlink in<br>
my case is not in the base directory. Additionally, I have replaced<br>
the symlink with a null mount and the problem persists.<br>
<br>
The problem I'm seeing, can be illustrated here:<br>
<br>
with symlink or null mount:<br>
<br>
FLUSH /usr/local/rrd/myproject/repository/local/switches/myswitch/<br>
10146.rrd<br>
0 Nothing to flush: /usr/local/rrd/myproject/repository/local/switches/<br>
myswitch/10146.rrd.<br>
<br>
real file location:<br>
<br>
Flush /usr/local/rrd/myproject/rrd/switches/myswitch/10146.rrd<br>
0 Successfully flushed /usr/local/rrd/myproject/rrd/switches/myswitch/<br>
10146.rrd.<br>
<br>
Where:<br>
<br>
/usr/local/rrd/myproject/reporsitory/local is a symlink (or null<br>
mount) to /usr/local/rrd/myproject/rrd<br>
<br>
I have the impression "rrdcached" is storing the full path of the RRD<br>
files internally, and only accepts a FLUSH command if the path is<br>
exactly the same as used in "rrd_update".<br>
<br>
Can you please confirm if this is the correct behavior?<br>
<br>
If that's just how rrdcached works, I believe we should update the<br>
documentation to highlight the importance of using the exact same path<br>
from "rrd_update" when flushing.<br>
<br>
If that's not desirable, and rrdcached is meant to be able to handle<br>
different paths, then I believe there's something wrong with the<br>
software's logic somewhere in the code (sorry, I didn't really check<br>
the source code).<br>
<br>
I'm probably going to rewrite my application to use the same path both<br>
in rrd_update and rrd_graph, however I think it would be better if the<br>
path was not a problem for the flush command (i.e. if a flush command<br>
is received and there's a symlinkt in the path, the real location<br>
could be calculated in order to find the file that needs to be flushed).<br>
<br>
Thanks for your attention,<br>
Eduardo Bragatto.<br>
<br>
_______________________________________________<br>
rrd-developers mailing list<br>
<a href="mailto:rrd-developers@lists.oetiker.ch" target="_blank">rrd-developers@lists.oetiker.ch</a><br>
<a href="https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers" target="_blank">https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers</a><br>
</blockquote></div><br><br clear="all"><br></div></div><font color="#888888">-- <br> kevin brintnall =~ /<a href="http://kbrint@rufus.net/" target="_blank">kbrint@rufus.net/</a><br><br>
</font></blockquote></div><br><br clear="all"><br>-- <br> kevin brintnall =~ /<a href="http://kbrint@rufus.net/">kbrint@rufus.net/</a><br><br>