Hi Ruben,
I have committed a patch in the CVS that should be beneficial to
the issue you reported. Can you pull latest code from CVS and let
me know it appears to solve your issue? If not i have got in mind
a second piece of code to touch.
Cheers,
Paolo
On Wed, Feb 05, 2014 at 08:28:17AM +0100,
Another thing I noticed was the lack of markers in the output files.
Had forgotten this is now controlled by the config. So after enabling
it, I get files like these:
--START (1391596920+60)--
DST_IP,PACKETS,BYTES
192.168.0.1,1059620,48742520
--END--
192.168.0.1,62895128,2893175888
--END--
Not
Cause for the memory usage has been found:
print_cache_entries: 91
This was needed when I was testing with random destination IP
addresses. As our production environment will only be accounting for say
1 IPs, this value might not need tweaking.
Regards,
Ruben
On 2014-02-05 08:28,
Hi Paolo,
See inline...
On 2014-02-04 18:26, Paolo Lucente wrote:
Configuration looks allright. And it can't supposedly happen with
libpcap that you have packets for the current (and/or future time
slots) when writing to the file: this might happen with nfacctd
instead, ie. in case NetFlow time
Hi Ruben,
Configuration looks allright. And it can't supposedly happen with
libpcap that you have packets for the current (and/or future time
slots) when writing to the file: this might happen with nfacctd
instead, ie. in case NetFlow timestamps are in future because of
routers not being NTP sync'
Hi,
I'll start with my config:
daemonize: true
pidfile: /var/run/pmacctd.pid
syslog: daemon
aggregate: dst_host
interface: eth5
plugins: print[traffic]
print_output_file[traffic]: /tmp/traffic-eth5-%Y%m%d_%H%M.txt
print_output[traffic]: csv
print_refresh_time[traffic]: 60
print_history[traffic]:
