Wrt1900ac-v1 crashe, fanctrl.sh failures

Installing and Using OpenWrt
1

hello. for the past ~3 weeks, my wrt1900ac-v1 has been crashing intermittently, it is functioning as a backupa ccess poijt (radios turned off in ususal operation) and a an iperf3 server for various networrk tests.
since 24.10, and back on snapshot since release of 24.10, this issue occurs. consistently, and wheterr or not it crashes, these entries recur in the log:

Thu Feb 13 11:19:00 2025 cron.err crond[1989]: file root:
Thu Feb 13 11:19:00 2025 cron.err crond[1989]:  line /sbin/fan_ctrl.sh
Thu Feb 13 11:20:00 2025 cron.err crond[1989]: wakeup dt=60
Thu Feb 13 11:20:00 2025 cron.err crond[1989]: file root:
Thu Feb 13 11:20:00 2025 cron.err crond[1989]:  line /sbin/fan_ctrl.sh
Thu Feb 13 11:20:00 2025 cron.err crond[1989]:  job: 0 /sbin/fan_ctrl.sh
Thu Feb 13 11:20:00 2025 cron.err crond[4473]: child running /bin/ash
Thu Feb 13 11:20:00 2025 cron.err crond[1989]: USER root pid 4473 cmd /sbin/fan_ctrl.sh
Thu Feb 13 11:20:10 2025 cron.err crond[1989]: wakeup dt=10
Thu Feb 13 11:21:00 2025 cron.err crond[1989]: wakeup dt=50
Thu Feb 13 11:21:00 2025 cron.err crond[1989]: file root:
Thu Feb 13 11:21:00 2025 cron.err crond[1989]:  line /sbin/fan_ctrl.sh
Thu Feb 13 11:22:00 2025 cron.err crond[1989]: wakeup dt=60

iperf3 is running in daemon mode. i can pretty reliably now crash it just by running a test over the lan; then it is no longer running, but the daemon can be re-launched. i cannot find a log entry for its crash.

thoughts?
thx

2

execute fanctrl in foreground, to catch the failures ?

3

yes, it's in the background. i have this in my local startup:

# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

/usr/bin/iperf3 -s -D

exit 0
4

I meant the fan script.

5

the fan script is has been put as a scheduled task with each run of sysupgrade. this is the cron file form the scheduled task luci page

# mamba fan script runs every 5 minutes
*/5 * * * * /sbin/fan_ctrl.sh

i dont think it was there prior to the last few weeks. if i delete it, it gets re-added with any sysupgrade.

6

and how is it related to what you were asked to do in my 1st post ?

7

i'm sorry -
i think the fan script trigger crashes the iperf3 daemon.
if i run the iperf command in the foreground, it does not crash

8

I was actually referring to the script.
if you can force a crash by putting some load onto the device, makes me think it isn't doing what it's supposed to...

9

the cron job for fan_ctrl.sh still runs every minute, even after I run the fan_ctrl script manually.

if i comment out all lines in /etc/crontabs/root and reboot, i still get cron errors:

Thu Feb 13 16:40:50 2025 authpriv.notice dropbear[3410]: Password auth succeeded for 'root' from 192.168.1.157:53941
Thu Feb 13 16:41:00 2025 cron.err crond[1987]: wakeup dt=60
Thu Feb 13 16:41:00 2025 cron.err crond[1987]: file root:
Thu Feb 13 16:42:00 2025 cron.err crond[1987]: wakeup dt=60
Thu Feb 13 16:42:00 2025 cron.err crond[1987]: file root:
Thu Feb 13 16:43:00 2025 cron.err crond[1987]: wakeup dt=60
Thu Feb 13 16:43:00 2025 cron.err crond[1987]: file root:

if i run the fan_ctrl.sh script manually, it doesnt change the crash during iperf loading.

i don't undertand why the cron errors contnue - they are new.
i'm curious if they appeared when the changes to the mvebu dts kmod:

?
anyway - i'm resetting everything and starting afresh. i'll update this post with followup

thx

10

Might try replacing the cron job with the procd fan control

11

update - after reset to default setting on snapshot r28800, the problem still occurs : if fan_ctrl fires during an iperf test, then iperf crashes.

@anomeome -
resetting to default now enters the crontab fan_ctrl script.
even if i take out the crontabs script, the fan_ctrl.sh is getting triggered. i can't seem to disable it. this is a new finding. i never saw the errors in logs before.