Every time CLD crashes, I find my logs filled up with error messages.
But running without them is no good either, so I don't want to remove
this message entirely. Let us try some filtering.

Actually, I am still considering if we should not reset the error
to zero whenever a packet is recived successfuly, but this seems to
work well in practice.

Signed-Off-By: Pete Zaitcev <[email protected]>

---
 server/cldu.c |   12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

commit 1c2d867711e4fe62d2ba4dd2f334e0e44a8ff7fa
Author: Master <[email protected]>
Date:   Thu Jan 14 19:57:43 2010 -0700

    Filter error messages from UDP receives.

diff --git a/server/cldu.c b/server/cldu.c
index 1d61672..9cda87e 100644
--- a/server/cldu.c
+++ b/server/cldu.c
@@ -53,6 +53,7 @@ struct cld_session {
        struct cldc_udp *lib;           /* library state */
        struct event lib_timer;
        int retry_cnt;
+       int last_recv_err;
 
        /*
         * For code sanity and being isomorphic with conventional programming
@@ -226,7 +227,16 @@ static void cldu_event(int fd, short events, void 
*userdata)
 
        rc = cldc_udp_receive_pkt(sp->lib);
        if (rc) {
-               applog(LOG_INFO, "cldc_udp_receive_pkt failed: %d", rc);
+               if (rc != sp->last_recv_err) {
+                       if (rc < -1000)         /* our internal code */
+                               applog(LOG_INFO,
+                                      "cldc_udp_receive_pkt failed: %d", rc);
+                       else
+                               applog(LOG_INFO,
+                                      "cldc_udp_receive_pkt failed: %s",
+                                      strerror(-rc));
+                       sp->last_recv_err = rc;
+               }
                /*
                 * Reacting to ICMP messages is a bad idea, because
                 *  - it makes us loop hard in case CLD is down, unless we
--
To unsubscribe from this list: send the line "unsubscribe hail-devel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to