Multiple log daemons?

Is it possible to run more than one log daemon and direct different facilities output to different daemons?

The logging with a circular buffer on OpenWrt is fine. I find that the log fills up with messages from:

  • hostapd
  • odhcpd
  • dnsmasq-dhcp
    which can obscure/overwrite other (sometimes more important) messages, like ones from dropbear.

I would like to give the more chatty facilities each their own log/circular buffer and leave standard syslog as the destination for the less frequent messages.

Is this easily achievable? I can imagine needing to run several log daemons, which would be fine, but if the system is not designed to do this, it might not be easily done.

My ideal would be to run several circular buffers, but for logread to integrate them, putting a marker in the output indicating the time at which a particular buffer starts, so that the most recent messages give full coverage, but as you go back in time you eventually lose the most to least chatty logs until there are none left. This would enable the least storage usage with the most useful (recent) log information.

Obviously, I can direct each facility to log to its own file, but that risks filling up the filesystem. The in-memory circular buffer is elegant.

I think the standard solution is to install syslog-ng, then configure filters to limit/route logs as needed.


Thank-you for the recommendation.

Looking into syslog-ng, it seems someone thinks rsyslog is better for OpenWrt

But, as far as I can tell, neither option offers the use of a ring buffer implementation as the target for log entries to be written to. I could wish for a standard filesystem layer that provided exactly that, so one could redirect log output to a ring buffer masquerading as a standard filesystem file.

I'm not the only one to have this wish:

Gitlab: CircFS - This single file implements a basic "circular buffer file"

While I don't expect this to appear any time soon in OpenWrt, I hope enough people find this itchy.

Other resources:

emlog is a Linux kernel module that makes it easy to access the most recent (and only the most recent) output from a process. It works just like "tail -f" on a log file, except that the storage required never grows. This can be useful in embedded systems where there isn't enough memory or disk space for keeping complete log files, but the most recent debugging messages are sometimes needed (e.g., after an error is observed).

ulogbufd. Make your logfile a FIFO and set ulogbufd to watching it. ulogbufd will maintain a set number of lines of data in its internal FIFO. Upon receipt of a signal, it can dump its queue either to a regular file, or to screen (with the aid of ulogbufdump). It's true, I would really rather not have had a separate daemon to do this, but it was almost unavoidable. dmesg was my inspiration, but dmesg uses a kernel buffer, and if you wanted to be able to create dmesg-like capability for other files, you'd have to have a place in the filespace for them to write to, and put capability for reading it in the kernel, and have a tool that could look at that message buffer...all somewhat beyond my capabilities, and less portable, too.