This is normal log, the logs are expected behavior.
Please wait for the issue reproduced and export the log to us.
TIA!
I installed the second, syslog, version a couple of days ago. Sample output during what appears to be normal operation is as follows:
Sun Mar 30 23:30:00 2025 user.debug LED: (rc.common:2) turnoff
Sun Mar 30 23:30:00 2025 user.debug LED: (rc.common:2) turnoff_led
Sun Mar 30 23:30:00 2025 user.debug LED: (rc.common:67) gl_i2c_led off
Mon Mar 31 07:00:00 2025 user.debug LED: (rc.common:2) turnon
Mon Mar 31 07:00:00 2025 user.debug LED: (rc.common:2) turnoff_led
Mon Mar 31 07:00:00 2025 user.debug LED: (rc.common:67) gl_i2c_led off
Mon Mar 31 07:00:00 2025 user.debug LED: (rc.common:6) turnon_led
Mon Mar 31 07:00:00 2025 user.debug LED: (rc.common:10) led_daemon
This is somewhat different from the first, led.txt, version reported by @D.D. Firstly, the sequence to turn-on the LED is different from that to turn-off the LED. Secondly, quite why the code appears to execute both turn-on and turn-off functions during the LED turn-on event is strange.
However, there is another issue. The syslog fills-up with other events so fast that the 780 line log fills within less than a minute and then pushes the LED event entries out. This makes it difficult to collect the LED event output unless I sit and wait for it!
The vast majority of these other events are errors like this:
Mon Mar 31 07:25:25 2025 kern.warn kernel: [501413.952103] siwifi_calculate_legrate invalid legrate: 4
Mon Mar 31 07:25:25 2025 kern.warn kernel: [501413.957526] siwifi_calculate_legrate invalid legrate: 6
Mon Mar 31 07:25:25 2025 kern.warn kernel: [501413.977823] siwifi_calculate_legrate invalid legrate: 4
Mon Mar 31 07:25:25 2025 kern.warn kernel: [501413.983431] siwifi_calculate_legrate invalid legrate: 6
Mon Mar 31 07:25:25 2025 kern.warn kernel: [501413.993154] siwifi_calculate_legrate invalid legrate: 4
Mon Mar 31 07:25:25 2025 kern.warn kernel: [501413.998579] siwifi_calculate_legrate invalid legrate: 6
There are hundreds of them generated per minute, often more than 40 per second. These entries are effectively a repeat of the kernel log with timestamps added. Often they completely fill the 780 line log in less than 1 minute. Surely there should not be so many errors constantly being generated?
[Update] I have seen elsewhere in the forums, from over a year ago, that this is a message generated by the chipset driver, which "can be ignored". Surely if this is flooding the log making it almost impossible to see 'real' problems, it needs to be corrected or filtered out as it's making the SysLog almost useless for practical debug purposes.
I shall continue to monitor the LED events over the coming days.