Update MerlinAU.sh Logging Solution to Stop Duplicating Mount Points#48
Update MerlinAU.sh Logging Solution to Stop Duplicating Mount Points#48Martinski4GitHub merged 4 commits intodevfrom
Conversation
|
I also adjusted the timeouts for the actual flash/curl. I know, I hear you saying "WHAT!?!?!?! WE JUST DISCUSSED THIS?!" But, hear me out, I am actually doing flashes with the curl over and over again in all these tests while I know you have only done it once so far. The reason I'm extending the actual reboot timer, and lowering the curl timer, why? Because 99% of the time, the curl completes instantly, and the script moves on, that's not the correct location where we should put longer wait/pause.. The upload is done instantly over it's own "local interface". There is no actual "networking" being done on the "upload" since it's already local. Normally we wait for the upload to complete from our device to the router, but in this case it returns within seconds because it's local already. The kill wait we implemented is literally only for that 1% of the time when it fails. The rest of the time (99%) we want the longest wait to be once the curl completes and turns, it "should" reboot itself once updated, but if it doesn't after 90 seconds we handle it for the router after about 90 seconds once the "curl/upload" is done. Basically:
|
Ah, OK. I get it now. That makes sense and explains why with the previous "sleep 60" the F/W Update would work most of the time since, as you said, the "curl" command itself likely takes less than a second to complete; the rest is the actual flashing of the image after shutting down most services, any external user space processes (e.g. Entware services, scripts, etc.) and unmounting any USB-attached drives. So I agree that 90 seconds should be sufficient. Good call. |
Bingo! I hope that 90 seconds is long enough. Really what we could do is extend the 90 to 3 minutes like the default. So we 'allow' the curl to take up to 3, but expect it to be done within seconds, and then 'allow" the flash and reboot to take up to 3 minutes, or we reboot it ourselves. I think that might even be better before we promote to production, but I'll wait on your opinions, your 2 cents are always appreciated haha. |
I was thinking about that as well while making the changes for PR #49. I fully agree that to be on the conservative side we should increase the 90-sec wait before rebooting to 3 minutes. IOW, both wait times (one for the curl command & one for reboot) should be 3 minutes. My preference is to err on the side of caution. |
Do it. I think we originally had something like this (6 minutes total) but we compromised, but we compromised the wrong way hahaha! It's okay we caught it early and live and learn. 3 and 3 is the safest bet. |
Indeed we did. We had the right idea but the wrong locations. I'll make the changes now. |
Tested and successfully solves my issues as discussed here: #47