Hello! I have a general question: I know that right after you boot a router, it doesn't know the right time yet, till it reaches time-server. Is /proc/uptime correct even before the router gets the correct time? I am trying to make a script for rebooting at a certain time: I want to save the statistics, then boot, and then restore the statistics, around 3am. In order to avoid boot-loop, I thought about something like
uptime="$(cut -d' ' -f1 /proc/uptime)";
if [ $uptime -ge 1800 ] ; then
sleep 5
/etc/config/bin/storeStats.sh
sleep 5
reboot
This way, the whole process would start only if the router is up for at least 30min, and if the router is working normally, it should be synchronized with the timeserver within a minute, so I could avoid boot-loop.
But this won't work, if /proc/uptime is wrong right after booting.
I don't plan on rebooting often, but right now I see something weird with the memory usage, I want to clear it up while everybody is still sleeping, perhaps once in the next few days.
I would not bet on "precise" ticking. My impression is that you can easily vary 5 to 10 seconds in a relatively short time. but once a day it might not matter.
If the ntp protocol is working normally a normal full synchronization is done within about 30-40minutes.
The ntp will start with a 5 very fast syncs to get something useful to start with and then make synchronization updates time longer and longer until it reaches about 32min update interval and settle there then it is seen as fully synced with ntp time.
And you can see in the boot system log when the time shift from seconds to real time how long it takes to have any useful time to begin with, but I would be surprised if you actually have any “time” before 1min.
I have a cript which determines if a reboot is required, so I added to the cron an entry without parameter. Also is called at boot time for logging purposes so I added to rc.local a call with a parameter 'boot'.
In the script I check de parameter. If the script is called with 'boot' parameter it doesn't reboot, it doesn't care about time in those cases. If it is called without the parameter it does it's stuff.
I'm not sure if this still applies but back in the day some wireless firmware had mysterious bugs and regular reboots prevent that. It's also not a bad tactic at all to do reboots once a day or at least every couple of days.
Regarding flunky drivers: The wireless community in germany (freifunk) noticed odd behavior especially on cheap devices.
So the rationale is/was: Either spend lot of time and money to replace el cheapo devices, and spend even more time while trying to replace all devices in the field; or just fire a reboot every couple of days to avoid bugs and glitches.
My impression from the first post was simply the question, how accurate is the uptime, even when time is not synced.
Again, why would regular reboots hurt in the first place?
??? So if you are stuck with buggy hard/software this might be an tolerable work-around, but if possible I think these bugs should be fixed and/or the hard/software should be replaced...
IIRC we (read as OpenWrt folks) have no influence of the actual wireless firmware binary blob thingsy running on the chip. ndb once explained some tech details to me but I got horribly drunk that night so I did not remember/understood everything...
And if you can not update the firmware (because no access), and if you got no money to replace hundreds of wireless nodes, then a reboot every 36 hours doesn't sound that bad
Oh, I am fully with you that this can be an acceptable/tolerable work-around for practically too hard to fix issues. And then it gets murky, as "too hard" is pretty subjective
Hundreds of devices per OpenWrt user seems to be abit over the top efter spending a lot of years around the forum. One, maybe two devices per user seems more likely.
Bad drivers requiring reboot sound very much like Linksys SOP since they separated from Cisco.
But isn’t it the kind of the basic idea with OpenWrt to not be forced to reboot all the time?
Its not unusual to see a couple of hundred nodes managed by a handful of people within the Freifunk in Germany. I also know of some small business where 1 or 2 dudes maintain dozen of installations each with ~ 50 nodes.
IIRC some ath chips had issues too, like crashing if too many 80211 mesh-nodes where visible in the air.
Thank you all for your replies ! It's gotten more exciting than I had thought:)
I don't know this concept, but am I right, that you meant that /proc/uptime works independent of time synchronization?
Thanks for the info! Then I will make if [ $uptime -ge 3600 ] ; then
to avoid boot-loop.
I didn't say that. I said that I want to reboot once in the next few days while everybody including myself is sleeping (around 3am). The reason is, there are zombies that are eating the memory. I know who they are, and I know that I can't kill them unless I reboot the router. But I still have a lot of room, so it can wait a few days, till I really figure out how to set up the reboot, with storestat before and restorestat after, without boot-loop. I don't want to get up at 3 and do things.
I have TP-link EAP 245's (with stock firmware), and they seem to do better after I set them to reboot once a day. (set over Omada controller) I started with once a week, then figured that it really helps better if I do it every night.
What does this file do? I think, if I touch something under /etc, then actually the time would be correct pretty much right after booting. But, in fact, even though I don't plan on setting reboot every night at this point, I might end up doing so, and I don't want to write something under /etc every night, unless there is another purpose for /banner. That's why I thought about using uptime, to avoid writing.
In any case, I'm super worried about boot-loop.
I would like to know the answer to this question, too. Does it wear something out?
Have had 2 of these and now I have EAP653 (always on stock firmware), something must be faulty with yours because these are 24/7 pretty much forever active AP. They never need reboots.
but once a day it might not matter.