Hi Paolo,

I see this behaviour with non empty purge events.

Here is a print out of all variables listet in the TRIGGER_VARS file as
seen by the script:

sql_startup_delay == 0

SQL_DB =  pmacct
SQL_TABLE =  acct_%Y%m%d
EFFECTIVE_SQL_TABLE =  acct_20180309
SQL_HOST =
SQL_USER =  pmacct
SQL_REFRESH_TIME =  300
SAMPLING_RATE =
SQL_RECOVERY_BACKUP_HOST =
TOTAL_ELEM_NUMBER =  4649
EFFECTIVE_ELEM_NUMBER =  4622
INSERT_QUERIES_NUMBER =  1
UPDATE_QUERIES_NUMBER =  0
ELAPSED_TIME =  1
SQL_HISTORY_BASETIME =  1520631900
SQL_HISTORY_TIMESLOT =  300
SQL_MAX_WRITERS =  10
SQL_ACTIVE_WRITERS =  0


sql_startup_delay != 0

SQL_DB =  pmacct
SQL_TABLE =  acct_%Y%m%d
EFFECTIVE_SQL_TABLE =
SQL_HOST =
SQL_USER =  pmacct
SQL_REFRESH_TIME =  300
SAMPLING_RATE =
SQL_RECOVERY_BACKUP_HOST =
TOTAL_ELEM_NUMBER =
EFFECTIVE_ELEM_NUMBER =
INSERT_QUERIES_NUMBER =
UPDATE_QUERIES_NUMBER =
ELAPSED_TIME =
SQL_HISTORY_BASETIME =
SQL_HISTORY_TIMESLOT =
SQL_MAX_WRITERS =  10
SQL_ACTIVE_WRITERS =



What would be the recommended way for the script to check if the purge
event was empty? My script would have probably failed on an empty purge
event.

What information do you need from me to be able to reproduce the problem?


Johannes
-- 
On 03/09/2018 03:54 PM, Paolo Lucente wrote:
> 
> Hi Johannes,
> 
> Do you see that behaviour - the reduced amount of environment variables
> being set - in coincidence with empty purge events? That is zero entries
> pushed to the database? If yes: that actually was intended behaviour and
> it still kind of makes sense to me; maybe i would refine it by still
> setting the SQL_ACTIVE_WRITERS variable. Would you see things in a
> different way? If no: then it's a bug and we can follow-up by unicast
> email since i was unable to reproduce it.
> 
> Paolo 
> 
> On Thu, Mar 08, 2018 at 12:05:48PM +0100, Johannes Maybaum wrote:
>> Forgot to mention I am using pmacctd to read accounting data from
>> several interfaces to be stored in a mysql db for further processing.
>> I see this effect in pmacct v1.6.1 as well as in v1.7.0.
>> Obviously the script started using sql_trigger_exec is running into some
>> problems... ;-)
>>
>> On 03/08/2018 03:04 AM, Johannes Maybaum wrote:
>>> Hi,
>>>
>>>   I am having a problem with the environment variables that is run after
>>> the cache is pruged(sql_trigger_exec). As soon as I set
>>> sql_startup_delay, some environment variables are not set anymore.
>>>
>>> sql_startup_delay not set:
>>>
>>> set | grep SQL  ->
>>>     EFFECTIVE_SQL_TABLE=acct_20180308_02
>>>     SQL_ACTIVE_WRITERS=0
>>>     SQL_DB=pmacct
>>>     SQL_HISTORY_BASETIME=1520472300
>>>     SQL_HISTORY_TIMESLOT=300
>>>     SQL_MAX_WRITERS=10
>>>     SQL_REFRESH_TIME=300
>>>     SQL_TABLE=acct_%Y%m%d_%H
>>>     SQL_USER=pmacct
>>>
>>>
>>> sql_startup_delay set:
>>>
>>> set | grep SQL  ->
>>>     SQL_DB=pmacct
>>>     SQL_MAX_WRITERS=10
>>>     SQL_REFRESH_TIME=300
>>>     SQL_TABLE=acct_%Y%m%d_%H
>>>     SQL_USER=pmacct
>>>
>>>
>>> Has anybody else seen this problem?
>>>
>>>
>>> thanks,
>>>
>>> Johannes
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
> 

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists

Reply via email to