-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Paolo,
On 11/02/2006 12:26, Paolo Lucente wrote:
> On Sat, Feb 11, 2006 at 11:19:39AM +0000, Ivan A. Beveridge wrote:
>
>> Can I do this by creating a corefile aswell (and then do a backtrace on
>> the corefile)? This is what I've done before, but those programs/daemons
>> didn't have separately-running 'modules' (like the memory module).
Here goes, on the latest "crash":
=================================
Feb 11 11:23:18 pink sfacctd-debug[15663]: INFO ( default/core ): Start
logging ...
Feb 11 11:23:18 pink Process [default][15663]: INFO ( default/core ):
waiting for data on UDP port '6500'
Feb 11 11:23:18 pink [fdrypeer][2395]: OK ( fdrypeer/memory ): waiting
for data on: '/var/run/pmacct_fdrypeer.pipe'
Feb 12 23:00:04 pink Process [default][15663]: ERROR: connection lost to
'fdrypeer-memory'; closing connection.
Feb 12 23:00:04 pink Process [default][15663]: ERROR: no more plugins
active. Shutting down.
=================================
pink pmacct # gdb -c core sfacctd-debug
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".
Core was generated by `sfacctd: IMT Plugin [fdrypeer]
'.
Program terminated with signal 6, Aborted.
#0 0x217ed802 in ?? ()
(gdb) bt
#0 0x217ed802 in ?? ()
#1 0x2185b991 in ?? ()
#2 0x2194edac in ?? ()
#3 0x00000000 in ?? ()
=================================
pink pmacct # file sfacctd-debug
sfacctd-debug: ELF 32-bit LSB shared object, Intel 80386, version 1
(SYSV), not stripped
=================================
Hrmph - that was useless. Any reason why I'd not be seeing anything
useful in the trace? I thought it only looked like that if the binary
was stripped :( I compiled with '-g':
=================================
[EMAIL PROTECTED] ~/src/pmacct-0.10.0 $ make clean
test -z "pmacct " || rm -f pmacct
test -z "pmacctd nfacctd sfacctd" || rm -f pmacctd nfacctd sfacctd
rm -f *.o core *.core
[EMAIL PROTECTED] ~/src/pmacct-0.10.0 $ make
gcc -DPACKAGE=\"pmacctd\" -DVERSION=\"0.10.0\" -DIM_LITTLE_ENDIAN=1
- -DHAVE_MMAP=
1 -DHAVE_L2=1 -DHAVE_PCAP_H=1 -DHAVE_LIBPCAP=1 -DPCAP_7=1
- -DPCAP_TYPE_linux=1 -DSTDC_HEADERS=1 -DHAVE_SYS_WAIT_H=1
- -DHAVE_GETOPT_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_TIME_H=1
- -DHAVE_U_INT64_T=1 -DHAVE_U_INT32_T=1 -DHAVE_U_INT16_T=1
- -DHAVE_U_INT8_T=1 -DHAVE_64BIT_COUNTERS=1 -DRETSIGTYPE=void
- -DHAVE_VSNPRINTF=1 -I. -I. -O2 -g -c pmacct.c
gcc -DPACKAGE=\"pmacctd\" -DVERSION=\"0.10.0\" -DIM_LITTLE_ENDIAN=1
- -DHAVE_MMAP=1 -DHAVE_L2=1 -DHAVE_PCAP_H=1 -DHAVE_LIBPCAP=1 -DPCAP_7=1
- -DPCAP_TYPE_linux=1 -DSTDC_HEADERS=1 -DHAVE_SYS_WAIT_H=1
- -DHAVE_GETOPT_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_TIME_H=1
- -DHAVE_U_INT64_T=1 -DHAVE_U_INT32_T=1 -DHAVE_U_INT16_T=1
- -DHAVE_U_INT8_T=1 -DHAVE_64BIT_COUNTERS=1 -DRETSIGTYPE=void
- -DHAVE_VSNPRINTF=1 -I. -I. -O2 -g -c strlcpy.c
<snip>
=================================
> Sure you can ! Just a further thought: if your pmacctd is exposed to a
> sustained packet rate, try also resizing the ring buffer between the
> Core Process and the Memory Plugin. However if this is the problem,
> you should been able to find some hints into your log. Some suggested
> values follow (feel free to modify but i recommend to keep the ratio):
>
> plugin_pipe_size: 10240000
> plugin_buffer_size: 10240
OK - will try this. I'm not sure what pps I'm getting, but we're
sampling ~30Gbps traffic currently (that'll rise to 90Gbps soon-ish and
certainly upwards in the coming months). That would be across 2
(probably) memory plugins.
Is there any way to see the default settings? (CONFIG-KEYS says that
default size depends on the OS). In "INTERNALS" file you mention about
"average_traffic = pps in network segment" - do you mean pps of sflow
data (in my case), or pps of traffic that will be sampled?
I'm going to try adding the above suggested plugin settings for the
moment, and will probably try compiling & using the rc2 snapshot you put
out. It looks like I need to tweak something else for the backtrace to
be of use though - let me know what / thoughts!
One trivial comment, with regards to text docs with the source - would
you make sure that line-length is < 80 chars, or it wraps horribly on
most people's terminals.
Cheers
Ivan
- --
Ivan Beveridge
<[EMAIL PROTECTED]> http://www.linx.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFD8JFEQQZN5jq7vncRAo7iAJ9Yx1/SUig3x6ioTJu/7RBeYMrmogCfVhoy
otIGCS+w5TxJdexzna4t6u8=
=xHdB
-----END PGP SIGNATURE-----
