Why is logread is spammed with cron.err messages?

Installing and Using OpenWrt
1

I have what I believe to be a valid crontab entry:

% crontab -l
0 3 * * 0 /usr/sbin/fstrim -a

But if I grep for fstrim in the output of logread I am finding a line one-per-min like this:

Sun Jun  8 10:17:00 2025 cron.err crond[3007]:  line /usr/sbin/fstrim -a
Sun Jun  8 10:18:00 2025 cron.err crond[3007]:  line /usr/sbin/fstrim -a
Sun Jun  8 10:19:00 2025 cron.err crond[3007]:  line /usr/sbin/fstrim -a

That doesn't seen right.

2
2 Likes
3

In busybox, based on the options used at build time for OpenWrt (for minimizing the footprint), there is no crond log type other than error. That is to say that everything it reports comes out as error instead of something like info or warn. Therefore, you can ignore the scary error part and almost always just assume it is an informational logging message.

1 Like
4

Thanks! I am happy to see when the command is executed but that once-per-min status is a bit nuts.

The default it seems is: `option cronloglevel '5'
Setting it to 6 suppressed the noise but logs the commands getting run.

1 Like
5

...what package sets up the default value? I wonder if having it use a default of 6 is more sane.

6

Please read the commit. BusyBox cron only uses levels 5,7,8, where 5 is now debug and 7 and 8 are normal logging. Use 7 as default.

You can remove the cronloglevel entry from /etc/config/system unless you want to log cron debug (5).

2 Likes
7

Interesting... I have mine set to 6 and it is no longer logging once-per-min. Is the above still correct?

8

That is correct.
Busybox upstream an ancient bug in cronloglevel handling for 5, and it was basically co-op earlier, although it had meant to be debug.
Luci has mistakenly placed 5 as placeholder earlier, and that then caused the log spam in the last busybox version upgrade in master last year.

1 Like