btw… if amtm does the auto updates, what does the in-script (in MerlinAU e.g.) actually do, just run independently anyway on a cron (duplicate amtm au?) i.e. is it redundant, additive or you put so much work into it’s hard for you to say goodbye to it ?
Keep in mind that MerlinAU has to handle and manage 2 types of automatic updates:
1) Automatic F/W Updates
2) Automatic Script Updates
This means that the built-in "
Automatic Script Updates" in MerlinAU is a bit more nuanced than the usual script update because we also have the "
Automatic F/W Updates" to consider, and therefore, we must be very careful not to run both updates too close together to avoid "stepping on each other's toes."
So, to remove any possible scheduling conflicts between the two
Automatic Updates, MerlinAU clearly and explicitly prevents users from setting up a separate cron job schedule for the "
Automatic Script Updates." Instead, it takes the existing cron job schedule already configured for the "
Automatic F/W Updates" and automatically schedules the "
Script Updates" to happen
15 minutes *
before*. This way, we avoid cron scheduling conflicts and any possible runtime issues between the two Automatic Updates by removing human errors from the equation.
Now, in the event that AMTM includes the option to set up its own cron job schedule to perform fully automated script updates, there is a possible scenario where a user may inadvertently schedule the AMTM script updates to happen either at the same time or very close to when the MerlinAU "
Automatic F/W Updates" are scheduled to occur.
If that happens, there is a chance that the
Automatic F/W Update and the eventual reboot of the router may leave some script update(s) in a *
corrupted* state because the process was interrupted as "the rug was pulled out from under their feet."
The above scenario might be rare and unusual, but the chances are
not ZERO, so to prevent it from happening, I've already implemented in MerlinAU a mutually exclusive, non-blocking FLOCK mechanism so that at some point, AMTM can check if the Lock is already taken *
before* proceeding to start its automatic script updates. And, in the reverse scenario, MerlinAU also checks the Lock *
before* starting the F/W Updates.
In short, the goal is to keep one update process from interrupting the other.