After thinking things through a bit more, I'll likely approach all of
this slightly different.
The goal is to keep the chance of config errors/mismatches/etc to a
minimum. Which made me try to make pmacctd's configuration file the only
place where "variable" info (interface names, paths, etc) would be stored.
However, the approach I'm currently investigating is more of a template
thing: create a single configuration file which contains all variable
info, and use that to create the various configuration files and scripts
based in various templates.
This should also make for easier adoption/modification/etc for others,
if I decide to make it all public (assuming I'll be ever be satisfied
enough with the result).
Regards,
Ruben Laban
On 18/Apr/2012 21:25, Ruben Laban wrote:
Hi Paolo,
Got me a nice new challenge with print_trigger_exec:
I have 4 plugins loaded in/out and total/per-ip each. So every
$print_refresh_time I get 4 new files. So far, so good. However, getting
to work print_trigger_exec cleanly for me remains a bit of a challenge,
because:
* You can't specify arguments to the script, so you'd need uniquely
named scripts for each plugin. Even though the only difference would be
in which directory it should look for files.
* When configuring a "global" print_trigger_exec, it gets executed 4
times. Which is asking for race conditions and would require
implementing locking.
So ideally I'd have one or more of the following:
* When print_trigger_exec is defined globally, only execute it
"globally". Meaning: at any given interval, only execute once.
* Allow to pass arguments to script to be executed.
* Provide plugin's name (and possibly other info as well) to the script
at execution time (similar to the sql_trigger_exec I think?).
Or, perhaps you know/see a different (existing?) solution for this
challenge?
Regards,
Ruben Laban
On 11/Apr/2012 19:09, Paolo Lucente wrote:
Hi Ruben,
Yes, I definitely agree :-) Thinking at it, it should be good idea to
include timezone information there. Noting this one down.
Cheers,
Paolo
On Wed, Apr 11, 2012 at 01:01:50PM +0200, Ruben Laban wrote:
It's actually much simpler. Each file already contains the required info
(though its presence does depend on your config). For example:
--START (1334141100+300)--
Start + interval = all the (timestamp related) info I need
No need to check file ctimes and/or parse configs. I'm guessing relying
on this piece of information is as good as any other solution, if not
better.
Regards,
Ruben
On 29/Mar/2012 23:02, Paolo Lucente wrote:
Hi Ruben,
The risk of #2 is that if anybody accidentally does anything with
the file, you might be screwed. It's also true you insert data in
RRD shortly after the file is created so the probability is slim.
But in this sense you can perhaps consider relying on file ctime
rather than mtime.
Relying on the file name is IHMO the way to go. Depending on how
you are inserting data in a RRD file, your option #1 looks OK to
me (granted that you define somewhere the config in use and parse
it accordingly - or more simply you define the step explicitely).
Cheers,
Paolo
On Thu, Mar 29, 2012 at 12:42:05PM +0200, Ruben Laban wrote:
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
_______________________________________________
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
