thanks, I doubled MAXMSG_CLIENT MAXMSG_STATUS as well as MAXMSG_DATA
from their default values. That seem to have eliminated the truncation
line for PORTS data and oversize status/stachg messages for Hobbitd.<br>
after "/etc/init.d/hobbit stop" and 'kill -TERM' the remaining vmstat processes, I had to 'ipcrm' one last shm segment. <br><br><div><span class="gmail_quote">On 8/6/06, <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 04, 2006 at 09:54:04AM -0400, Jerry Yu wrote:
<br>> one of our servers have  up to 6000 TIME_WAIT tcp connections from time to<br>> time. This got truncated, of course.  I want to see them all. any quick way<br>> to change the upper limit w/o recompilation ?
<br><br>Set the MAXMSG_CLIENT setting in hobbitserver.cfg and restart Hobbit.<br>The default is 512 (KB) for the maximum size of a client message.<br><br>If you want them all to show up on the status display, you probably also
<br>have to increase the MAXMSG_STATUS setting.<br><br>The hobbitserver.cfg man-page describes these.<br><br><br>> Also, for the same server, from time to time, certain checks 'stopped<br>> reporting' [ files & msgs, in particular ] for some extended period,
<br>> sometimes over 35m, while other checks kept going. I wonder if the message<br>> truncation triggered by the over-sized [ports] section caused this loss.<br><br>It could very well be due to this. The [files] and [msgs] sections of
<br>the client message appear after the network ports listing, so if the<br>message was truncated these could be lost.<br><br><br>Regards,<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>