C recvfrom breaking syslog

Question

I've recently been writing a netflow receiver in C that listens for netflow via UDP. Once it processes the flow datagram, it writes it to syslog. My problem is that once I receive a datagram packet with the standard recvfrom function, my messages no longer make it to syslog. I am receiving and processing the data just fine, but the syslog writing isn't working. The code looks like this

setlogmask(LOG_UPTO(LOG_NOTICE));
openlog("netflow_receiver", LOG_CONS, LOG_LOCAL2);
syslog(LOG_NOTICE, "Syslogger started");

while(1){

    syslog(LOG_NOTICE, "Top of loop");
    unsigned char* mesg = (unsigned char*)malloc(1024 * sizeof(unsigned char));
    syslog(LOG_NOTICE, "Allocated message memory");

    len = sizeof(cliaddr);
    syslog(LOG_NOTICE, "Got len of client");

    //Syslog stops after this
    n = recvfrom(sockfd, mesg, 1024, 0, (struct sockaddr *) &cliaddr, &len);
    syslog(LOG_NOTICE, "received");
    mesg[n] = 0;

    syslog(LOG_NOTICE, "Calling log_record");
    process_record(mesg);
    syslog(LOG_NOTICE, "Back from log_record");

}

The syslog looks just like this

Dec 12 09:42:01 my_pc netflow_receiver: Syslogger started
Dec 12 09:42:01 my_pc netflow_receiver: Top of loop
Dec 12 09:42:01 my_pc netflow_receiver: Allocated message memory
Dec 12 09:42:01 my_pc netflow_receiver: Got len of client
Dec 12 09:48:33 my_pc netflow_receiver: Syslogger started
Dec 12 09:48:33 my_pc netflow_receiver: Top of loop
Dec 12 09:48:33 my_pc netflow_receiver: Allocated message memory
...

Any thoughts or suggestions...I'm open to using a non-standard C syslog library if anyone knows about a good one.

[Please don't cast the return value of `malloc()` in C](http://stackoverflow.com/a/605858/28169). Also don't scale by `sizeof (char)`, it's always 1 so it adds nothing to the code's quality but adds a lot of noise. Your allocation should just be: `unsigned char* msg = malloc(1024);`. Blam. — unwind, Dec 12 '13 at 10:52
thanks for the casting advice on malloc. Never had any problems with it before but that's good to know. I will likely however always use `needed_size * sizeof(type)` because it's my coding style and I like to be sure that I'm getting the right amount from malloc regardless of how implicit it is. — Tommy, Dec 12 '13 at 22:29

score 0 · Answer 1 · answered Dec 12 '13 at 10:50

0

it's most probably not recvfrom's fault. you can check this by commenting out the recvfrom() line and rerun your application.

syslog drops messages from processes with high load of messages if you need all these logs consider logging to a file and using a logging library (e.g log4cxx, ...)

answered Dec 12 '13 at 10:50

arash kordi

2,470
1
22
24

I tried that and it proceeded to print the rest of the syslog messages. And I'm sure that I'm not overloading the syslog message load. I had another app that did the same as this c code but it was in java, and it was logging thousands of messages a second with no trouble. Plus I was testing with a sample file that only had a single packet in it. I would simply `cat sample | nc -u 127.0.0.1 6789` to test. Thanks for your input though :) – Tommy Dec 12 '13 at 23:15

score 0 · Accepted Answer · answered Dec 12 '13 at 10:57

0

mesg[n] = 0; is wrong

If recvfrom returns 1024, your're indexing into memory outside what you should.

Same thing if recvfrom returns -1.

Make sure you handle both those cases.

You'll want to make sure sockfd actually has the correct value of your socket, syslog opens a socket too, if you have some error somewhere and start reading from that file descriptor instead, odd things will happen.

answered Dec 12 '13 at 10:57

nos

223,662
58
417
506

you are absolutely right about the `mesg[n] = 0` bit. totally wasn't looking at that and that subtle bug has been fixed, but I don't believe that is what caused the syslog troubles. Oddly enough, it's just working now. Don't know what I did any different but everything is making it to syslog (even before I fixed this bug). – Tommy Dec 12 '13 at 22:41
That's what happens when you overwrite rather random things in memory, odd things happen. Unless you're lucky and it crashes. – nos Dec 12 '13 at 22:45
I'll conclude that this is the primary suspect. Thanks for the help – Tommy Dec 12 '13 at 23:11

C recvfrom breaking syslog

2 Answers2