Fix Multiple GNUton Mount Points

[ExtremeFiretop]

Issue reported by scootertramp on snbforums here: https://www.snbforums.com/threads/backupmon-v1-10-2-2026-may-24-backup-restore-your-router-jffs-nvram-external-usb-drive-encrypt-cifs-smb-nfs-available-in-amtm.93052/post-994663

The problem appears to be caused by multiple MerlinAU startup processes... such as "startup", "addCronJob", and "postUpdateEmail" running at the same time and reaching the GNUton webs_update.sh patch logic before being properly serialized. This created a race condition where processes shared temporary files, moved the same files, and sometimes stacked multiple bind mounts on /usr/sbin/webs_update.sh.

Below is an example of me recreating the problem using the following command:
sleep 5; /jffs/scripts/MerlinAU.sh startup & /jffs/scripts/MerlinAU.sh addCronJob & wait

Here was the result of that command:

BEFORE:

Admin@RT-AX92U-5EB0:/tmp/home/root# df -h
Filesystem Size Used Available Use% Mounted on
ubi:rootfs_ubifs 69.4M 64.4M 5.1M 93% /
devtmpfs 199.5M 0 199.5M 0% /dev
tmpfs 199.6M 384.0K 199.3M 0% /var
tmpfs 199.6M 1.8M 197.8M 1% /tmp/mnt
mtd:bootfs 5.1M 4.2M 980.0K 81% /bootfs
mtd:data 8.0M 3.2M 4.8M 40% /data
tmpfs 199.6M 1.8M 197.8M 1% /tmp/mnt
tmpfs 199.6M 1.8M 197.8M 1% /tmp
/dev/mtdblock9 63.0M 4.0M 59.0M 6% /jffs
/dev/sda1 3.6G 1.0G 2.4G 30% /tmp/mnt/USB3
tmpfs 199.6M 1.8M 197.8M 1% /www/index_style.css
tmpfs 199.6M 1.8M 197.8M 1% /www/require/modules/menuTree.js
tmpfs 199.6M 1.8M 197.8M 1% /www/state.js

TEST RUN:

Admin@RT-AX92U-5EB0:/tmp/home/root# sleep 5; /jffs/scripts/MerlinAU.sh startup & /jffs/scripts/MerlinAU.sh addCronJob & wait
mv: can't rename '/jffs/addons/MerlinAU.d/logs/RT-AX92U_FW_Update_2026-06-10_15_45_54.log': No such file or directory
mv: can't rename '/jffs/addons/MerlinAU.d/logs/RT-AX92U_FW_Update_2026-06-10_15_45_54.log.SAVED.TEMP.LOG': No such file or directory
mv: can't rename '/jffs/addons/MerlinAU.d/webs_update.sh.GNUTON.DL.TMP': No such file or directory
mv: can't rename '/jffs/addons/MerlinAU.d/webs_update.sh.GNUTON': No such file or directory

AFTER:

Admin@RT-AX92U-5EB0:/tmp/home/root# df -h
Filesystem Size Used Available Use% Mounted on
ubi:rootfs_ubifs 69.4M 64.4M 5.1M 93% /
devtmpfs 199.5M 0 199.5M 0% /dev
tmpfs 199.6M 384.0K 199.3M 0% /var
tmpfs 199.6M 1.8M 197.8M 1% /tmp/mnt
mtd:bootfs 5.1M 4.2M 980.0K 81% /bootfs
mtd:data 8.0M 3.2M 4.8M 40% /data
tmpfs 199.6M 1.8M 197.8M 1% /tmp/mnt
tmpfs 199.6M 1.8M 197.8M 1% /tmp
/dev/mtdblock9 63.0M 4.0M 59.0M 6% /jffs
/dev/sda1 3.6G 1.0G 2.4G 30% /tmp/mnt/USB3
tmpfs 199.6M 1.8M 197.8M 1% /www/index_style.css
tmpfs 199.6M 1.8M 197.8M 1% /www/require/modules/menuTree.js
tmpfs 199.6M 1.8M 197.8M 1% /www/state.js
/dev/mtdblock9 63.0M 4.0M 59.0M 6% /usr/sbin/webs_update.sh
/dev/mtdblock9 63.0M 4.0M 59.0M 6% /usr/sbin/webs_update.sh

The fix was to place entire initialization (log cleanup and the GNUton download/compare/mount sequence) behind a dedicated blocking flock, while also using PID-specific temporary filenames and checking operation return codes.

Since the issue can no longer be reproduced, the concurrency race appears resolved to me?
Any ideas or suggestions you have or would like to share?

[Martinski4GitHub]

Issue reported by scootertramp on snbforums here: https://www.snbforums.com/threads/backupmon-v1-10-2-2026-may-24-backup-restore-your-router-jffs-nvram-external-usb-drive-encrypt-cifs-smb-nfs-available-in-amtm.93052/post-994663

Great catch by user scootertramp from the SNB Forums!!

The problem appears to be caused by multiple MerlinAU startup processes... such as "startup", "addCronJob", and "postUpdateEmail" running at the same time and reaching the GNUton webs_update.sh patch logic before being properly serialized. This created a race condition where processes shared temporary files, moved the same files, and sometimes stacked multiple bind mounts on /usr/sbin/webs_update.sh.

Nice sleuthing and great investigative work!!!
Yeah, the startup and addCronJob calls have a chance to run concurrently, and there was no lock mechanism protecting some of the initialization operations.

Below is an example of me recreating the problem using the following command: sleep 5; /jffs/scripts/MerlinAU.sh startup & /jffs/scripts/MerlinAU.sh addCronJob & wait

....

The fix was to place entire initialization (log cleanup and the GNUton download/compare/mount sequence) behind a dedicated blocking flock, while also using PID-specific temporary filenames and checking operation return codes.

You've got the right idea for the solution, but there's no need for a new, dedicated blocking flock mechanism. We already have a readily available blocking lock implementation to do what's needed for this scenario.

CORRECTION:
Actually, the separate, dedicated FLOCK blocking mechanism to protect the initialization routines is a cleaner and leaner implementation for fast operations, so it can be used here. Good call!!👍

Since the issue can no longer be reproduced, the concurrency race appears resolved to me? Any ideas or suggestions you have or would like to share?

I'll merge this PR and then submit my changes in another PR. Essentially, the approach to the solution is correct, but it needs some improvements and fine-tuning.