<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.28.2">
</HEAD>
<BODY>
I think I know why.<BR>
My editor converted tab to space and I bet your file is tab indented.<BR>
<BR>
You probably have to just edit the hobbitfetch.c file and add the couple lines and edit the other two.<BR>
I will see about getting a patch against the 4.3.0-beta2 files and a 4.2.3 one if it is needed.<BR>
<BR>
<BR>
On Wed, 2010-02-10 at 09:33 +0000, Steinar M. Skúlason wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
    <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    On Mon, Feb 8, 2010 at 6:53 PM, Cade Robinson <<A HREF="mailto:cade.robinson@gmail.com">cade.robinson@gmail.com</A>> wrote:<BR>
    <BLOCKQUOTE>
        The issue is in the hobbitfetch "grabdata" function.<BR>
        <BR>
        int n;<BR>
        char buf[8192];<BR>
        ...<BR>
        n = read(conn->sockfd, buf, sizeof(buf));<BR>
        ...<BR>
        else if (n > 0) {<BR>
        ...<BR>
        buf[n] = '\0';<BR>
        ...<BR>
        <BR>
        If the "read" reads 8192 bytes then n is 8192 and then buf[n] tries to<BR>
        get set to NULL.  There is no element 8192.<BR>
        Also only one read happens so if there is more than 8192 bytes to be<BR>
        fetched not everything is fetched.<BR>
        <BR>
        I put the "read" and "if"s in a do...while loop and fixed the null<BR>
        termination on buf and haven't had any issues.<BR>
        <BR>
        ~/hobbitmon/trunk/hobbitd:-> diff -u hobbitfetch.c ./hobbitfetch.c.new<BR>
        --- hobbitfetch.c       2010-02-08 12:43:22.781543905 -0600<BR>
        +++ ./hobbitfetch.c.new 2010-02-08 12:52:25.249509306 -0600<BR>
        @@ -342,8 +342,9 @@<BR>
            int n;<BR>
            char buf[8192];<BR>
        <BR>
        +    do {<BR>
            /* Read data from a peer connection (client or server) */<BR>
        -        n = read(conn->sockfd, buf, sizeof(buf));<BR>
        +        n = read(conn->sockfd, buf, sizeof(buf)-2);<BR>
            if (n == -1) {<BR>
                if ((errno != EINTR) && (errno != EAGAIN)) {<BR>
                    /* Read failure */<BR>
        @@ -360,7 +361,7 @@<BR>
                /* Save the data */<BR>
                dbgprintf("Got %d bytes of data from %s (req %lu)\n",<BR>
                    n, addrstring(&conn->caddr), conn->seq);<BR>
        -        buf[n] = '\0';<BR>
        +        buf[n+1] = '\0';<BR>
                addtobuffer(conn->msgbuf, buf);<BR>
            }<BR>
            else if (n == 0) {<BR>
        @@ -380,6 +381,7 @@<BR>
                    break;<BR>
                }<BR>
            }<BR>
        +    } while (n>0);<BR>
         }<BR>
        <BR>
         void set_polltime(clients_t *client)
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BR>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BR>
        <BR>
        <BR>
        <BR>
        <BR>
        <BR>
        <BR>
        On Mon, 2010-02-08 at 18:12 +0000, Steinar M. Skúlason wrote:<BR>
        ><BR>
        ><BR>
        > On Mon, Feb 8, 2010 at 5:36 PM, Daniel McDonald<BR>
        > <<A HREF="mailto:dan.mcdonald@austinenergy.com">dan.mcdonald@austinenergy.com</A>> wrote:<BR>
        >         On 2/8/10 10:37 AM, "Steinar M. Skúlason"<BR>
        >         <<A HREF="mailto:steinarms@gmail.com">steinarms@gmail.com</A>> wrote:<BR>
        ><BR>
        >         > Hi,<BR>
        >         ><BR>
        >         > I'm having problems with "msgcache" on the client machines<BR>
        >         and "hobbitfetch"<BR>
        >         > on the server machine.<BR>
        >         > It works for a short period and then get's stuck and all my<BR>
        >         client side checks<BR>
        >         > end up with status purple.<BR>
        ><BR>
        ><BR>
        >         Yup.  Been doing that for a long time here.  I sent a bunch of<BR>
        >         corefiles to<BR>
        >         Henrik about it, and he tried a bunch of patches.  Eventually,<BR>
        >         we just wrote<BR>
        >         a routine that restarts hobbitfetch whenever a host turns<BR>
        >         purple.<BR>
        ><BR>
        >         --<BR>
        >         Daniel J McDonald, CCIE # 2495, CISSP # 78281<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>
        ><BR>
        > Ok, good to hear that I am not the only one.<BR>
        > I wrote a ugly routine that restarts hobbitfetch if there is no new<BR>
        > entry in the logfile<BR>
        ><BR>
        ><BR>
        > #!/bin/bash<BR>
        ><BR>
        > #This is to see if any progress has been made within the hobbitfetch<BR>
        > utility.<BR>
        > TMP_FILE=/tmp/tmp.hobbitfetch.last<BR>
        > LAST_LINE=`tail -1 /usr/lib/xymon/server/log/hobbitfetch.log|awk<BR>
        > '{print $1 $2}'`<BR>
        > PREV_LINE=`cat /tmp/tmp.hobbitfetch.last`<BR>
        > echo $LAST_LINE > $TMP_FILE<BR>
        ><BR>
        > if [ "$LAST_LINE" == "$PREV_LINE" ]; then<BR>
        >   echo "Nothing has happend .... killing hobbitfetch!"<BR>
        >   PID=`ps -ef|grep hobbitfetch|awk '{print $2}'`<BR>
        >   kill -9 $PID<BR>
        > fi<BR>
        ><BR>
        > Best Regards,<BR>
        > Steinar M.<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>
        <BR>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    Thank you for your reply Cade, I tried your patch but it was not working for me<BR>
    are you using the 4.3.0-beta2 for both client and server?<BR>
    I get no checks populated with your changes.<BR>
    Or did you also make changes to the msgcache.c ?<BR>
    <BR>
    Regards,<BR>
    Steinar M.
</BLOCKQUOTE>
</BODY>
</HTML>