Logd doesn't honor conloglevel (17.01.4, r3560-79f57e422d)

Hi!

In LEDE Reboot (17.01.4, r3560-79f57e422d) in order to log only highest level messages the conloglevel in /etc/config/system has been set to some low value (a 1 in this particular example), followed by '/etc/init.d/log stop' then '/etc/init.d/log start'.

However logd doesn't honor the settings, please see below, same info & notice are being logged to syslog server.

Is this a [known] bug?

Thanks!

root@caribou2:~# cat /etc/config/system | grep log
        option ttylogin '0'
        option log_size '64'
        option log_proto 'udp'
        option log_ip '192.168.193.2'
        option cronloglevel '8'
        option conloglevel '1'
root@caribou2:~# logread -f
Wed Nov  1 19:44:32 2017 daemon.info hostapd: wlan0: STA f0:99:bf:5a:89:d7 IEEE 802.11: authenticated
Wed Nov  1 19:44:32 2017 daemon.info hostapd: wlan0: STA f0:99:bf:5a:89:d7 IEEE 802.11: associated (aid 1)
Wed Nov  1 19:44:32 2017 daemon.notice hostapd: wlan0: AP-STA-CONNECTED f0:99:bf:5a:89:d7
Wed Nov  1 19:44:32 2017 daemon.info hostapd: wlan0: STA f0:99:bf:5a:89:d7 RADIUS: starting accounting session BA9E86EE2092AFCE
Wed Nov  1 19:44:32 2017 daemon.info hostapd: wlan0: STA f0:99:bf:5a:89:d7 WPA: pairwise key handshake completed (RSN)

I am not sure it is an issue.

Since openwrt CC, logd replaced syslogd and it won't take any options except -S. So conloglevel might not change logd.

However /proc/sys/kernel/printk will be changed by init script. So kernel log message will not be printed to console if level higher than conloglevel. Still those messages could be seen by dmesg or logread.

It is an issue for those who need to be in control of what user space daemons log.

With the advent of logd which is totally uncontrollable what are my options regarding syslog level filtering at the source?

Thank you.

1 Like

Replace it with another syslog implementation like syslog-ng

Is anyone successfully using syslog-ng with recent LEDE revs?
Config samples are welcome.
Just trying to avoid opening whole new can of worms :wink:

Found below links and it looks someone has opened this can of worms already.

https://wiki.openwrt.org/doc/howto/log.syslog-ng3
https://baheyeldin.com/technology/linux/logging-with-syslog-ng-on-openwrt.html

Thank you, your kind assistance is very much appreciated! Have a good one!

As already said, but I'd like to second that, logd should honor log levels. The local log buffer is not so much of a problem, but logd does sound out events of all loglevels to my remote syslog server, this is not so very useful. Everything below "warning" should stay local.

Will test syslog-ng3 now, however, logd should be improved to honor conloglevel.

I agree, actual 'logd' is a step backward. I need remote logging, to supervise a bunch of hotspots. Even when using one (remote) logfile per device, anyone is clobbered with a lot of non interesting messages.
May be, to give the "syslogd" from busybox a try. Which leads to the question, why to re-invent the logging, when there is such a tool already available ?

Because people are still trying to run 4/32 devices and remote logging has no value to many of them. They may never even look at the ring buffer logs.

I’m not sure why someone with the sophistication to use remote logging is complaining. The logging rate from OpenWrt is relatively low so it’s not like it’s saturating the network. Filter on the log host or install syslog-ng or rsyslog. Seems pretty silly not to be using TLS for remote logging as well, and I’d be surprised if busybox supports it.

1 Like