Skip to content

Maximum Lock Timeout for AMTM Call#553

Merged
ExtremeFiretop merged 1 commit intoExtremeFiretop:devfrom
Martinski4GitHub:dev
Mar 17, 2026
Merged

Maximum Lock Timeout for AMTM Call#553
ExtremeFiretop merged 1 commit intoExtremeFiretop:devfrom
Martinski4GitHub:dev

Conversation

@Martinski4GitHub
Copy link
Collaborator

Set the Maximum LOCK Timeout to a short value so that the AMTM call returns quickly when the script LOCK already exists.

Set Maximum LOCK Timeout to short value so that the AMTM call returns quickly when LOCK already exists.
@Martinski4GitHub
Copy link
Collaborator Author

@ExtremeFiretop,

What do you think about adding a mutually exclusive, non-blocking FLOCK mechanism in MerlinAU so that whenever AMTM initiates script updates, or MerlinAU starts an F/W Update, each script can check the FLOCK mutex to make sure only one of them can perform its intended operation without "stepping on each other's toes" and avoid any possible interruption?

The current LOCK mechanism in MerlinAU only serves to prevent a secondary instance of MerlinAU from running, but it's not designed for external scripts to check if MerlinAU is in the process of performing a F/W Update, which could cause any script update to end up being corrupted if it happens to be interrupted by the F/W update and the final reboot step.

As previously explained, the use case we're trying to avoid is unusual and rare, but the possibility is not zero, so the very small amount of code required to achieve the goal is worth the effort, IMO.

@ExtremeFiretop ExtremeFiretop merged commit 1cc1448 into ExtremeFiretop:dev Mar 17, 2026
1 check passed
@ExtremeFiretop
Copy link
Owner

Your a smart man Martinski.
Fully agreed, the risk is low but not zero, might as well guard against it if we can!

Merged!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants