Conversation
Added a background child process to simply wait for 6 minutes while the F/W Update is in progress. If after 6 minutes the curl process still exists, the background task kills it; otherwise does nothing & returns. This is our "escape hatch" to handle the rare possibility that the curl command never completes the F/W Update. If the F/W update completes normally, the background task will simply do nothing and may get terminated if the router reboots itself.
Added code to check if the router is reporting a new F/W Update is available so that we can modify the notification settings accordingly.
Added code to restart the WebGUI just before our own login is initiated to begin the actual F/W Update process. This ensures that nobody else is logged in at that moment so that we can do process without any interruptions.
|
All looks fantastic. I merged it in, seems simple but gives us an "out" if absolutely required in those rare instances. All I did was adjust some of the sleep timeouts here: 95cb571 As you originally described it can be lowered it from 6 minutes to 3 and a half. But really don't expect any router to take longer than 3 minutes as that is the default amount of time any of the WebUIs offers before a saying to manually reboot. I gave it an extra 30 seconds of play room over the default 3 minutes, just incase it happens to be going slightly over or something slightly unexpected happens, but any longer than that it is most likely frozen or a broken curl request and should be killed and tried again post-reboot. In my mind theres no need to have people waiting the extra 3 minutes on top of the default 3 minutes. :) One of those options where if we see three's signs wee need more time, we can extend it, but highly unlikely. |
...
I tend to be very conservative regarding time estimates, even with my own. For example, I always add 20% to 25% to my project task/deliverable estimates just to give me enough breathing room if something unexpected/unforeseen happens. When it comes to 3rd-party estimates, I may add up to 50% depending on my assessment of how conservative & experienced the "estimator" is & whether his previous estimates were on target. That's the reason I went double with 6 minutes because I don't know how accurate ASUS default time is. Also, I'm assuming that most of the time the F/W Update will be run automatically with nobody watching, so the extra 3 minutes seemed harmless. I'd rather have the extra time to ensure the F/W update is really "stuck" before killing it than end up killing the process as is about to finish and possibly resulting in a "bricked" router. OTOH, you're right that this is highly unlikely to happen, but I'd like to err on the side of caution. One "bricked router" due to the script would be too many (and would feel very responsible & guilty about it :>(. Anyway, my preference & suggestion (as a compromise) would be to have a 4-minute sleep before killing the process. I don't think the extra 60 seconds would be too much even if someone is doing it manually. When I've done it via the webGUI in the past, I normally get up and make myself a cup of coffee or grab something cold to drink (summer months) and take a little walk. By the time I come back, it's done. My philosophy is "a watched pot takes much longer to boil" so unless I'm testing or expecting trouble, I just let it do its thing while I take a few minutes of solitude :>). Just my 2 cents. |
|
So I tend to actually watch the firmware updates like a hawk everytime lol. Normally the update is done and rebooted before the 3 minute timer is up on the GUI. However thats a small sample of newer and powerful routers, I can't speak for all of them, which is why I'm good with the proposed compromise of 4minutes :) |
Yeah, I get it. When doing s/w dev. work that's still my M.O. as well. and used to be like that before in my younger years with personal projects when tinkering with home routers & whatnot. Nowadays, I've relaxed a little and take things a little easier on the homefront with my personal projects, hobbies, etc., and take my short walks while something is compiling/running/executing, just to relax and not worry too much. So I do understand where you're coming from. |
2 participants
Added a background child process to simply wait for 6 minutes while the F/W Update is in progress. If after 6 minutes the curl process still exists, the background task kills it; otherwise, it does nothing & returns. This is our "escape hatch" to handle the rare possibility that the curl command never completes the F/W Update. OTOH, if the F/W update completes normally, the background task will simply do nothing and may get terminated if the router reboots itself. I believe 6 minutes should be plenty of time to complete any F/W update, but we can increase it if/when needed.