Hi Paolo,
Thanks for the clarification.
Now to think of a nice way to deal with this "issue".
* Manually add the interval to the file's timestamp, or
* Rely on the file's mtime, or
* Ignore the problem and insert "inaccurate" data into the RRDs
None of those are really idea, tho I guess the 2nd one will turn out to
the most reliable.
Regards,
Ruben Laban
On 29/Mar/2012 09:01, Paolo Lucente wrote:
Hi Ruben,
That is intended. What is encoded in the filename is the basetime of a
timeslot, what in a SQL table would be the stamp_inserted field. The OS
timestamp of the file, ie. when the file was last touched, encodes what
in a SQL table would be the stamp_updated field instead.
Cheers,
Paolo
On Wed, Mar 28, 2012 at 11:14:48AM +0200, Ruben Laban wrote:
Hi Paolo, list,
Just now I noticed another unexpected behavior:
-rw------- 1 root root 402 2012-03-28 10:50
pmacct_up0_in_total_20120328-1045
-rw------- 1 root root 402 2012-03-28 10:55
pmacct_up0_in_total_20120328-1050
-rw------- 1 root root 402 2012-03-28 11:00
pmacct_up0_in_total_20120328-1055
The documentation states:
KEY: [ sql_table | print_output_file ]
DESC: ... Dynamic names are supported through the use of
variables, which are computed at the moment when data is purged to the
backend. ...
So I'd expect the file written at 10:50 to called -1050, not -1045.
Am I interpreting the documentation wrong, did I stumble upon a bug, or
something completely different?
Regards,
Ruben Laban
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
