anyway the size limit can be applied invididually for each check, such that an oversized [ports] or any other section won't vitimize other 'good' sections and cause them dataless in the RRD?

On 8/7/06, Jerry Yu <jjj863 at gmail.com> wrote:

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. after "/etc/init.d/hobbit stop" and 'kill -TERM' the remaining vmstat processes, I had to 'ipcrm' one last shm segment.

On 8/6/06, Henrik Stoerner <henrik at hswn.dk> wrote:

...

On Fri, Aug 04, 2006 at 09:54:04AM -0400, Jerry Yu wrote:

...

one of our servers have up to 6000 TIME_WAIT tcp connections from time to time. This got truncated, of course. I want to see them all. any quick way to change the upper limit w/o recompilation ?

Set the MAXMSG_CLIENT setting in hobbitserver.cfg and restart Hobbit. The default is 512 (KB) for the maximum size of a client message.

If you want them all to show up on the status display, you probably also

have to increase the MAXMSG_STATUS setting.

The hobbitserver.cfg man-page describes these.

...

Also, for the same server, from time to time, certain checks 'stopped reporting' [ files & msgs, in particular ] for some extended period, sometimes over 35m, while other checks kept going. I wonder if the message truncation triggered by the over-sized [ports] section caused this loss.

It could very well be due to this. The [files] and [msgs] sections of the client message appear after the network ports listing, so if the message was truncated these could be lost.

Regards, Henrik

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk