This one time, at band camp, Paolo Lucente wrote: >Hey Jamie, > >On Thu, Aug 18, 2005 at 01:03:09PM +1000, Jamie Wilkinson wrote: > >> pidfile: /var/run/pmacctd.test.pid >> debug: true >> aggregate: src_host,dst_host >> networks_file: /etc/pmacct/networks >> pcap_filter: vlan and ( net 202.4.224.0/20 or net 203.98.86/24 ) and not >> ((src net 202.4.224.0/20 or src net 203.98.86/24 ) and ( dst net >> 202.4.224.0/20 or dst net 203.98.86/24 ) ) >> interface: eth1 >> plugins: pgsql >> sql_host: localhost >> sql_passwd: x >> sql_table: acct_test >> sql_table_version: 4 >> sql_refresh_time: 60 >> sql_history: 1m >> sql_recovery_logfile: /var/lib/pmacct/recovery.test >> sql_dont_try_update: true >> sql_cache_entries: 15485863 > >[ ... ] > >Few things about the configuration which may help. You are noticing that the >connection >to PostgreSQL fails; is your PostgreSQL daemon listening on 127.0.0.1:5432 ? >The above >configuration sports a 'sql_host' line which tells the PostgreSQL library to >not use its >usual pipe file connectin but go TCP instead. Here might lie the trouble, let >me know.
Well, the postgresql config hasn't changed, it's listening on 0.0.0.0:5432 according to netstat --inet -lnp, and I can connect to it using psql and the same details as in the pmacct config. >About the error message; you are right: it's quite generic; i'll add a >specific text for >each of the 3 cases "lock failure", "unable to connect" and "at least one of >the queries >has failed" so that they are easily recognizable. Thanks. >About the recovery file creation; i've tested the above configuration just >discarding >the 'networks_file' and 'pcap_filter' lines. It has worked just fine. The file >has been >created and is consistent (i've used /tmp instead of /var/lib/pmacct). I'm getting a recovery log file now, I think it was some odd system behaviour, possibly just combinations of sql_cache and pipe_size, i.e. just transient and not a real problem. >In the end: 'sql_cache_entries' has a value of 15485863, that is, some more >than 15 million >entries. Entry size is approximatively some 60-70 bytes. It turns out that you >are trying >to reserve slightly mroe than 1Gb memory to the cache table. Do you have >enough memory (as >i've understood it, this is a test instance that runs in addition to a >production one) ? Yeah, that's the same setting as on the live pmacctd, I've removed it now to make sure the two of them aren't starving each other of memory. There's 1.5G in the machine so normally it's been ok. I might consider shortening the value once I can get 0.9.1 talking to the database though.
