Log options in /etc/config/system

I'm just about to configure logging in OpenWRT (18.06.1) on my GL-iNet AR300M router.

In /etc/config/system I can set several log options:

  • log_buffer_size (defaults to the value of log_size if unset)
  • log_size (size of the file based log buffer in KiB)
  • log_type ( circular or file)
  • log_file (file to write log messages to)
  • log_remote (0/1 = disable/enable remote logging)

What I want to do:

  1. write log messages to file in directory /tmp
  2. save logfile in /tmp via cron job to usb drive

I've set log_remote=0 and log_file=/tmp/syslog.log, but I don't know how to set log_type and log_size.

Without any logfile the meaning of log_type=circular is clear: when reaching the end of the buffer, new writes start at the beginning.

Is this also true, when I'm using a logfile? What happens, if the logfile exceeds the value of log_size? Does the next write start at the beginning of the logfile or is a new logfile created? In the latter case: what happens with the first logfile?

I hope to get some deeper insights.

Barney

Just use LuCI (the size and file location questions are definitely answered there):

Just make a cron job to run cp at the time interval of your choosing.

log_size and log_buffer_size are, as I recall, used interchangeably where one is checked first, then the other (see the wiki page for the order). Neither should matter significantly as the log buffer is circular and home usage is unlikely to go faster than it can be written to disk.

logrotate is what you'd need to handle on-disk log rotation.

Personally, I'd just log directly to the USB stick.

1 Like

Thanks for your reply.

Even if I concentrate on the options I can set via LuCI (log_size and log_file), then the following questions remain:

  1. What happens, if the logfile size exceeds the value of log_size?
  2. Is the logfile written in a circular manner like the RAM based log buffer?
  1. It rolls over.
  2. Yes, see answer 1.
  • Change the size to fix this.
  • Simply save to the USB.

Thanks for your reply.

And what about the logfile? What happens, if the logfile size exceeds the value of log_size?

I know.

I agree, but that doesn't work after (re)booting. Because the log daemon is started with no. 10 and external storage is mounted with no. 40, the logfile can't be created, when the log daemon is started. As a result there is no file logging. You have to restart the log daemon and therefore missing some messages. This is unacceptable e.g. when you have a regular cron based reboot.

At the moment I'm copytruncating the logfile in /tmp with logrotate to the usb stick just for archival purposes (until I find a better solution).

1 Like

The log buffer is circular, so as long as you don't log more than the 64 kB default, nothing is lost before your "standard" logger starts up (and as long as it can flush faster than 64 kB can be written, won't lose data either).

The default implementation of file-based logging just uses logread -f, as I recall, so it "misses" what's in the buffer when it starts up. You can resolve this in a couple of ways. Basically if you either or both capture dmesg into its own file and/or logread into your log file, then kick off logread -f, you should get it all.

If you've got very aggressive logging, you may need to increase the kernel log size in the kernel config itself. I've only had to do that with heavy debugging of early driver load.

Thanks for your reply.

That's an interesting idea, which I shall further investigate and test.

I tried to verify your statement and produced so many log messages, that the logfile size exceeded the value of log_size. Here's the result:

log_file=/tmp/syslog.log, log_size=512

After the logfile reached the limit of 512 KiB, openwrt moved /tmp/syslog.log to /tmp/syslog.log.old and created a new logfile /tmp/syslog.log. Here's the output of ls:

-rw------- 1 root root 100324 02.07.2019 15:32:52 syslog.log
-rw------- 1 root root 524300 01.07.2019 21:31:11 syslog.log.old

Here's the output of tail -n5 syslog.log.old:

Mon Jul  1 21:31:07 2019 kern.info kernel: [78590.957794] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
Mon Jul  1 21:31:07 2019 kern.info kernel: [78590.985282] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
Mon Jul  1 21:31:08 2019 kern.info kernel: [78592.586697] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
Mon Jul  1 21:31:09 2019 kern.info kernel: [78592.779289] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
Mon Jul  1 21:31:11 2019 kern.info kernel: [78594.942848] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready

Here's the output of head -n5 syslog.log:

Mon Jul  1 21:31:11 2019 kern.info kernel: [78594.973298] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
Mon Jul  1 21:31:11 2019 kern.info kernel: [78595.395372] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
Mon Jul  1 21:31:11 2019 kern.info kernel: [78595.435474] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
Mon Jul  1 21:31:12 2019 kern.info kernel: [78595.938996] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
Mon Jul  1 21:31:12 2019 kern.info kernel: [78595.974413] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready

So openwrt makes a simple kind of rotation. And so is my next question: how many versions?

In earlier versions of openwrt docs I found an option log_rotate, which seems to have the same meaning as the rotate option in logrotate. But log_rotate doesn't appear in the current docs of openwrt. Is the feature still present or does it vanish like in the docs?

If you tested that to be true, why don't you simply test further?

The answer to both your questions can simply be checked in the code. If it "vanished," as you say, then you can search the code revisions.

Are you under the impression that the parameters differ?

Found this question while searching for info on log rotation: in my experience, it seems only one older file is kept.