Henrik,<br>
I spoke too soon on the core dump. I just had another one
go this morning. Here is the stack trace (with the domain
commented out). <br>
<br>
<br>
Cheers,<br>
Brian<br>
<br>
[root@sac-pmon-02 tmp]# gdb ../bin/hobbitd_client core.29614 <br>
GNU gdb Red Hat Linux (6.1post-1.20040607.41rh)<br>
Copyright 2004 Free Software Foundation, Inc.<br>
GDB is free software, covered by the GNU General Public License, and you are<br>
welcome to change it and/or distribute copies of it under certain conditions.<br>
Type "show copying" to see the conditions.<br>
There is absolutely no warranty for GDB. Type "show warranty" for details.<br>
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/tls/libthread_db.so.1".<br>
<br>
Core was generated by `hobbitd_client'.<br>
Program terminated with signal 6, Aborted.<br>
Reading symbols from /usr/local/lib/libpcre.so.0...done.<br>
Loaded symbols for /usr/local/lib/libpcre.so.0<br>
Reading symbols from /lib64/tls/libc.so.6...done.<br>
Loaded symbols for /lib64/tls/libc.so.6<br>
Reading symbols from /lib64/ld-linux-x86-64.so.2...done.<br>
Loaded symbols for /lib64/ld-linux-x86-64.so.2<br>
#0 0x000000340232e4dd in raise () from /lib64/tls/libc.so.6<br>
(gdb) bt<br>
#0 0x000000340232e4dd in raise () from /lib64/tls/libc.so.6<br>
#1 0x000000340232fc8e in abort () from /lib64/tls/libc.so.6<br>
#2 0x000000000040d723 in sigsegv_handler (signum=29614) at sig.c:57<br>
#3 <signal handler called><br>
#4 0x0000000000402c86 in unix_disk_report (<br>
hostname=0x514aca "<a href="http://wal-dapp-02.x.x.x.com">wal-dapp-02.x.x.x.com</a>", hinfo=0x72ab40, <br>
fromline=0x7fffffffca70 "\nStatus message received from 10.3.3.146\n", <br>
timestr=0x514b26 "Tue Aug 16 15:38:43 GMT 2005", capahdr=0x40f036 "Capacity", <br>
mnthdr=0x40f02e "Mounted", <br>
dfstr=0x514cc6 "Filesystem", ' ' <repeats 11
times>, "1024-blocks
Used Available Capacity Mounted on\n/dev/md/dsk/d0",
' ' <repeats 11 times>, "3010671
1515862 1434596
52% /\n/dev/md/dsk/d6", ' ' <repeats 11 times>,
"1988887 1219506
709"...) at hobbitd_client.c:299<br>
#5 0x000000000040478b in handle_solaris_client (<br>
hostname=0x514aca "<a href="http://wal-dapp-02.x.x.x.com">wal-dapp-02.x.x.x.com</a>", hinfo=0x72ab40, <br>
sender=0x2aaaaabca268 "\2009@\0024", timestamp=0, clientdata=0x0) at solaris.c:52<br>
#6 0x0000000000405e2a in main (argc=5327601, argv=0x7fffffffd258)<br>
at hobbitd_client.c:827<br>
(gdb) <br><br><div><span class="gmail_quote">On 8/13/05, <b class="gmail_sendername">Henrik Stoerner</b> <<a href="mailto:henrik@hswn.dk">henrik@hswn.dk</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Fri, Aug 12, 2005 at 09:28:30AM -0700, Brian Lynch wrote:<br><br>> We are running the Solaris sar script from deadcat that dumps anywhere from<br>> 200K to 900K data via the 'status' channel.<br><br>Yikes! that's a lot more than I thought would go in a status message.
<br><br>I've now made these settings configurable in hobbitserver.cfg,<br>instead of having to change the source and re-compile. The default<br>for the status channel is still 256 kB, but you just add<br> MAXMSG_STATUS="1024"
<br>to your hobbitserver.cfg, and it will use that instead.<br><br>> the hobbitd_client channel has not core dumped since I put the<br>> latest snapshot in place.<br><br>Good to know.<br><br><br>Thanks,<br>Henrik<br>
<br><br>To unsubscribe from the hobbit list, send an e-mail to<br><a href="mailto:hobbit-unsubscribe@hswn.dk">hobbit-unsubscribe@hswn.dk</a><br><br><br></blockquote></div><br>