@beginner67890 I just had another reboot, and I can tell it is related to at least the processes sleep, tinyproxy and uhttpd (luci). Because I had a crash on all of the three. I dont have other resources running on the router, and if I deactivate all three of the above, the router is stable (20days no reboot, if I enable one of them, reboot will happen in the next days). The moment I use one of these, there is a large probability, it will sooner or later crash/reboot. I honestly dont know what you mean with "I just ran a test to sleep for just 1 second without difficulty" ? Like I said... these processes just rise the probability of a reboot. If I let a sleep 20 script run, the router will reboot in the next x days for sure. If I open Luci maybe 500 times, it will reboot one of the trys. If I use tinyproxy then whatever random time, it will reboot. If I let the router just "be", and have nothing run on it, and it just routes traffic, it is stable. OpenVPN also doesnt add to the instability, which I am using per default and had no instability issues. So my theory is, like I stated before, that it must be a process which is RAM related, whatever reason OpenVPN doesnt seem to be. But sleep, uhtpd and tinyproxy seem to be. Let this sh script run for a week or two and look if it gives any page faults via dmesg.
/root/test.sh &
#!/bin/sh
getStatus() {
ifconfig | grep $1 >/dev/null && (((ping -4 -c 2 -W 2 -I $1 8.8.8.8 | grep -v '0 packets received' | grep 'packets received') >/dev/null || (ping -4 -c 2 -W 2 -I $1 8.8.4.4 | grep -v '0 packets received' | grep 'packets received') >/dev/null)) && return 1
return 0
}
while true; do
getStatus eth1
if [[ $? == 0 ]]; then
sleep 5
else
sleep 5
fi
done
exit 0
(Last edited by makedir on 17 Jan 2018, 03:50)
