Hello Ivan, On Mon, Feb 06, 2006 at 05:01:44PM +0000, Ivan A. Beveridge wrote:
> This is my current logfile: > > ============================= > daemonize: true > pidfile: /var/run/sfacctd.pid > sfacctd_port: 6500 > sfacctd_ip: 127.0.0.1 > plugins: memory[fdrypeer] > aggregate[fdrypeer]: src_mac, dst_mac > imt_path[fdrypeer]: /var/run/sfacct_fdrypeer.pipe > syslog[fdrypeer]: local4 > imt_mem_pools_size: 65536 > ============================= > > * kill -USR1 on the core process seems to kill it (rather than dump > stats to console/log) Messy SIGNALS documentation, my fault; the ChangeLog tells the truth: SIGUSR1 is handled (nicely) just by pmacctd and it returns a pair of counters from libpcap. sfacctd and nfacctd actually don't support it (however they should either ignore the signal or handle it gracefully now on). In future, i think it's a good idea to add a kind of global counters and a bare summary screen (like: x Net/sFlow packet received, y errors encountered, z bad seq numbers, j missed datagrams, etc.) > * Nothing seems to get written to syslog (it would be nice to get at > least a startup/shutdown message as confirmation it works). This is because you attached the syslog directive to the 'fdrypeer' plugin (which is a memory plugin and has pretty nothing to log until the memory table is full or the memory is finished); try rewriting it 'syslog: local4'. > Other suggestions: > * pidfile does not get removed when process gets stopped/killed. > * way of 'automatically' getting the pid of the children for a > particular plugin (akin to being able to get the pid of core from the > pidfile). > * compile-time default location for config file Let me thank you for your suggestions. The first is clear and ok. About the second, a possible way: one specifies 'pidfile: <pidfile>' into his configuration; then <pidfile> remains the pidfile for Core Process, while <pidfile>.<type>.<name> can become the syntax for pidfiles for the active plugins (type and name are both needed as if more plugins are spawned and no specific name is attached to them, each name will default to 'default'). The third is tricky to achieve, instead: by default it's assumed the use of command-line options; this approach rewards in the fact that lets the user that has downloaded pmacct for the first time to understand what it does without being forced to get in touch with the configuration syntax. Lastly, i've read your following mail about how to retrieve the counters from the memory table; a way is parsing the output got from 'pmacct -s'. Of course, it's ok if you plan to do something with either all or the vast majority of the entries in your table. However, if this is not the case consider the following way: shell> pmacct -c sum_host -N "file:/path/to/queries.list" where queries.list contains the data to be matched, one per line: === 192.168.0.1 192.168.0.2 192.168.0.3 ... === It will batch all queries for you and could result in something definitely more tailored for your scenario. Of course, results will be shown one per line, same order of the list. Cheers, Paolo
