Hello Paolo,
Could you please tell about current state of this question.
Alex
On 04/19/2009 01:00:48 PM, Paolo Lucente wrote:
Hi Alex,
DST is not supported. Timezones are. The idea behind this was that a
backend application (like pmacct is) should ideally work only with UTC
(even if
hello world,
since i have changed my 'frontend' to slack64 on a e5520, pmacctd doesn't
create weekly tables any more on my 'backend' server.
it seems it doesn't even try..
when i create them manually, they get populated.
a typical sunday/monday switch looks like this:
__cut__
Aug 3
Hi Christian,
I'm not sure how a change to the frontend can influence that
way the backend. Two things to check: 'sql_history' is in use
(as it generates the timestamp used at a later stage to work
out the name of the dynamic table) and sql_table_schema file
is readable.
Moreover, something
hi paolo,
thank you very much for your fast response.
On Mon, Aug 03, 2009 at 12:31:11PM +0100, Paolo Lucente wrote:
I'm not sure how a change to the frontend can influence that
way the backend. Two things to check: 'sql_history' is in use
(as it generates the timestamp used at a later
hi paolo!
On Mon, Aug 03, 2009 at 12:31:11PM +0100, Paolo Lucente wrote:
[...]
Moreover, something related to dynamic SQL tables was fixed in
just released 0.12.0rc1 version - and it's been in the CVS for
quite a while. If you are not using either of these versions,
another chance is to
I've been searching the mail archives for info on this topic and found a
thread suggesting to running an instance of pmacctd per interface (using
the ifindex as the engine_id) and use the nfprobe plugin to export all
instances to nfacctd on localhost. Then in nfacctd I added a pre_tag_map
to map
