Chris Wilson <[email protected]> wrote: > On Mon, 13 Apr 2009, Johannes Formann wrote:
Hi Chris, > >>> I'll get this kind of error: Apr 13 15:27:15 server pmacctd[1341]: > >>> ERROR ( default/mysql ): Duplicate entry > >>> '0-00:1c:c0:74:5b:e9-00:00:0c:07:ac:6a-0-84.38.64.216-79.221.203.' for > >>> key 1 > >> > >> I get this as well. It means that the primary key is not long enough to > >> make the records truly unique. As you can see, it has been truncated. > >> Either find out how to make the key longer (and please let me know :) > >> or remove some aggregation fields, e.g. mac addresses and vlans. > > > > strange, The primary key could be up to 1000 bytes if I remember > > correctly, the whole row isn't that long. > > Perhaps the error message is being truncated and there really is a > duplicate of the entire row? You don't have multiple pmacctd's running by > any chance? I'm quite shure I don't. I've even deletet an rebuild the table (v4-type, should I try other/newer?) > >> I'm not sure why "flows" is in your aggregate set since flows are > >> already aggregated into flows in all cases by pmacctd, as far as I know > >> (please correct me if I'm wrong). > > > > flow isn't in the primary key. > > I didn't say it was, but it is in your aggregate set and I don't > understand why. Are you shure its flow, between mac and IP it could be vlan? > >>> Apr 13 15:27:15 server kernel: pmacctd[1341]: segfault at f7002991 ip > >>> 00000000f7bfa9ca sp 00000000ffb88334 error 4 in > >>> libpthread-2.3.6.so[f7bf2000+e000] > >> > >> And that should definitely not happen. Where did you get pmacct from? > >> Did you compile it yourself? Can you build a version with debugger > >> symbols and run it in gdb to get a backtrace (bt command) when it > >> crashes? > > > > Since I'd had similar problems with the debian version, I compiled it on > > my own. > > > > Since I hav't much experience with gdb, any hints, this seems to bee not > > the right way: > [...] > > (The error has been loged bevore I pressen ctrl+c) > > I guess you mean the SIGSEGV error has been logged in your syslog? gdb > should stop when it sees the SIGSEGV error, and wait for a command such as > "bt". So I guess it's happening in another thread than the main one, so it > will be harder to trace. > > You could wait until pmacctd is up and running, then press Ctrl+C, enter > the "info threads" command, then guess a thread other than the first one > and switch to it with "thread xxx" and "continue", and hope that that > thread dies with SIGSEGV. Is pmacctd not terminated once pressing ctrl+c? it looked like that when I tried once ctrl+c. But as seen in the other post, a coredump might have helped me. cheers, johannes _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
