Logging frameworks for embedded linux?

Question

I need a small, portable framework for logging on embedded linux. Ideally it would output to a file or a socket, and having some sort of log rotation/compression would also be nice.

So far, I've found a lot of frameworks, but almost all of them have daunting build procedures or require the use of application frameworks (e.g. log4cxx requires the Apache Portable Runtime, which I'd rather not bother with...).

Just looking for something simple and robust, but everything I seem to find is complicated or requires lots of secondary junk just to run.

Suggestions? (and if the answer is roll my own, that's fine, but...it's be great to avoid that)

Answer 1

Implementing very robust logging mechanism in C taking about 1000 code lines (from our code base). 90% of this defines of different sections. This includes different macros DBG_E DBG_W DBG_TRACE etc ... and spliting to the section, run time changing of debug level and debug modules (does not include compression just simple print abstraction that can be implemented in different ways file/socket/serial etc...) .
I will estimate that it take about few days to implement. The down side you will spend a few days the up side that you will get something that works for your needs and nothing more, i understand that you are working on embedded platform and footprint and memory usage are important, the best and optimized solution will be one you write. We invested those few days ones. and using it across different products/project and adjust/improve with the time past according to real needs. Main problem of generic solution that it usually will do sort of what you need and a lot more, this more usually just waist of resources.

Answer 2

I can't imagine that your platform is too small to include log4cxx and APR, neither is a large library, and even the tiniest platform is likely to have space for them.

You could just use syslog, which is provided by the C library - a syslog daemon is provided by busybox (which no doubt, you already use if you're on a really tiny platform). I don't know if busybox's syslogd can log to the network, but it has some level of flexibility. You can do log rotation using shell scripts pretty trivially.

Answer 3

http://www.qdecoder.org/api/qLog_8c.html

HTH

Answer 4

Use syslog(3) and syslogd from BusyBox. BusyBox can be very compact when stripped down and doesn't depend on anything other than libc. You can strip out everything you don't want so it is perfectly possible to use it only for logging.

We use BusyBox on a number of embedded systems, both Linux and uClinux, and find its logging facilities highly reliable.

Answer 5

@MarkR

Size has nothing to do with it. Porting and effort do; we're working on a tight schedule and the last thing I want to do is spend the next few weeks porting log4cxx and APR. Our team has very little experience with embedded linux, so I would much rather spend "porting" efforts to more vital components than a logging framework. It simply doesn't make sense to spend that much effort just to add logging to an embedded application on linux.

I'm going to go with log4c--it's much smaller, easier to compile and port, and has all of the basic requirements I need (including logging to file, a decent log-rotation implementation, syslog and stream output, etc.). It doesn't have socket logging, but creating such an appender looks fairly trivial.

the other logging frameworks are simply monstrous, and I have no desire to beat my head against someone else's code, especially when it meets no actual customer requirement.

Answer 6

Maybe you should consider spending some time on a good logging framework, since this is what you are going to use on your embedded Linux. ... and printf ...

I cooked something where I can enable/disable various logging levels per module in runtime.

Did you ever try debugging multithreaded apps on Linux?

Good luck!

Answer 7

I have no experience with the log4cxx-module but I am using APR on an embedded target running Linux (it is based on the Atmel AT91SAM926x processor family). It was really simple to configure and compile (more or less ./configure --host=arm-none-linux-gnueabi) so I would not be to afraid of going down the log4cxx-path.