spdMerlin spdMerlin v4.4.15 [2025-Nov-07] - Internet Speedtest and Monitoring Tool for AsusWRT Merlin

[ExtremeFiretop]

Are both of these files still valid? I suspect the script could be erroring out if one is not found. I thought all the Entware modules moved exclusively to amtm.

I believe . /jffs/addons/amtm/mount-entware.mod is still valid:

not sure what about: . /jffs/addons/diversion/mount-entware.div though.
Even if it's not valid though, the lines following in his post-mount are running as expected (such as tailmon)

cat /jffs/scripts/post-mount
#!/bin/sh
swapon /tmp/mnt/USB_120GB/myswap.swp # Added by amtm
. /jffs/addons/amtm/mount-entware.mod # Added by amtm
. /jffs/addons/diversion/mount-entware.div # Added by amtm
(sleep 30 && /jffs/scripts/tailmon.sh -screen) & # Added by tailmon

[ -x "${1}/entware/bin/opkg" ] && [ -x /jffs/scripts/spdmerlin ] && /jffs/scripts/spdmerlin startup "$@" & # spdMerlin

AsusAdmin@RT-AX88U_Pro-0998:/tmp/home/root#

And here is the systemlog confirming that part:

Jan  1 00:02:03 Entware: Starting Entware services on /tmp/mnt/USB_120GB
Jan  1 00:02:03 AsusAdmin: Started tailscaled from /jffs/scripts/post-mount.

 

[Martinski]

I've gone ahead and did a very quick spdMerlin code review. I found out -to my surprise- that force update, and update processes DO NOT check for the existence of the startup command line the script needs at router's boot up, or to be more specific, after a USB disk is mounted.

That's the wrong assessment. You're not reading the code correctly, or you're not doing the proper analysis to understand the execution flow. The check is always done after the add-on update (or force update) has completed.

 

[dave14305]

And here is the systemlog confirming that part:

Is that really from tailmon, or is it the Entware startup script running?
@alan6854321 should just run:
/jffs/scripts/post-mount /tmp/mnt/dummy

And see if it complains.

 

[ExtremeFiretop]

Is that really from tailmon, or is it the Entware startup script running?
@alan6854321 should just run:
/jffs/scripts/post-mount /tmp/mnt/dummy

And see if it complains.

That's a good point, I assumed it came from tailmon but it could be just the entware service.
Let's see what alan says with the test

 

[alan6854321]

That's a good point, I assumed it came from tailmon but it could be just the entware service.
Let's see what alan says with the test

Alan says "Yahoo - it works!"

 

[ExtremeFiretop]

Alan says "Yahoo - it works!"

This confirms the problem was solved by removing:

. /jffs/addons/diversion/mount-entware.div # Added by amtm

From the post-mount script.

Seems like maybe diversion left some remnants behind? Causing post-mount to fail to run the lines following.
Which means alan was likely having issues with both spdmerlin as well as tailmon.

 

[alan6854321]

A minor surprise, TAILMON sent me an Email, it's never done that before....

WARNING: Router Has Unexpectedly Restarted

Date/Time: Nov 13 2025 15:51:08

WARNING: TAILMON has detected that the router may have rebooted or was restarted. TAILMON.
has reset the service, and reestablished a connection to your Tailnet. Please investigate if this
behavior continues to persist.

Sent by the "tailmon.sh" script.
From the "RT-AX88U" router.

2025-Nov-13 Thu 03:51:08 PM GMT

 

[ExtremeFiretop]

A minor surprise, TAILMON sent me an Email, it's never done that before....

WARNING: Router Has Unexpectedly Restarted

Date/Time: Nov 13 2025 15:51:08

WARNING: TAILMON has detected that the router may have rebooted or was restarted. TAILMON.
has reset the service, and reestablished a connection to your Tailnet. Please investigate if this
behavior continues to persist.

Sent by the "tailmon.sh" script.
From the "RT-AX88U" router.

2025-Nov-13 Thu 03:51:08 PM GMT

Happy you found a solution! And it required no code changes!
I'd like to know more about why that was left behind in your post-mount though if it's no longer valid.

We may need to poke @thelonelycoder for that one though.

 

[alan6854321]

Seems like maybe diversion left some remnants behind? Causing post-mount to fail to run the lines following.

I just noticed your comment, but I've never run diversion on any of my routers (I use PiHole)
So how did that get there?

 

[ExtremeFiretop]

I just noticed your comment, but I've never run diversion on any of my routers (I use PiHole)
So how did that get there?

Interesting, then I'm not sure I'm qualified to answer that one.

Hopefully thelonelycoder has more of an idea where it comes from.

 

[Tarek Yag]

What would happen if I just ran the post-mount script in a terminal, would it cause problems?

Yeah, it might cause a lot of problems.
In general, running the "post-mount" script a second time in the same router boot cycle, will run second instances of each script called from there, which probably might cause various problems for already running scripts. It also might cause errors when trying to execute commands that shouldn't be executed twice in the same boot cycle.
This is the general case though. Most of the scripts in this community already deal with these problems with lock files and other proper means.
So FYI, no, running post-mount script a second time is totally a bad idea.

 

[Tarek Yag]

That's the wrong assessment. You're not reading the code correctly, or you're not doing the proper analysis to understand the execution flow. The check is always done after the add-on update (or force update) has completed.

I'm sorry to interrupt you, but I'm not that dumb nor that beginner to read code incorrectly or not do proper quick analysis. Although, it's always possible that we all do mistakes and sometimes even horrible ones. By the end of the day, we are all humans.
However, as I know exactly what I was taking about, I just did another code review but slower than my first, to better understand the code and follow more code paths than I previously did.

Actually, the check is NEVER done neither in the update process nor in the force update process itself. Precisely talking, it is done when the script is being started up after an update or force update is done.
So, if I decided not to start the script after the update process (or in other scenarios, for example, losing SSH connection right after the update), the function "Auto_Startup()" will never be executed, hence the startup code in "post-mount" is never checked in the update process.
However, regarding the check for startup code existence in "post-mount", it is there indeed with the script's startup too. I might have recalled it not being checked from a very old experiment which I talked about in a previous post of mine.

Sorry for any inconvenience!

 

[Martinski]

Actually, the check is NEVER done neither in the update process nor in the force update process itself. Precisely talking, it is done when the script is being started up after an update or force update is done.
So, if I decided not to start the script after the update process (or in other scenarios, for example, losing SSH connection right after the update), the function "Auto_Startup()" will never be executed, hence the startup code in "post-mount" is never checked in the update process.

Well, despite your 2nd attempt at reviewing the code and all that was said, you still didn’t do a proper analysis to follow the *complete* flow of execution, so your assessment is still wrong.

Again, if you read the code carefully, thoroughly, and pay attention to the details, you'll see that *after* the add-on update (or force update) has been completed (i.e. the files have been updated to their latest versions), the code *automatically* restarts the newly-updated script, which executes the code that runs all the regular checks. No user intervention is required at all to restart the script - none whatsoever.

In addition, you could have performed a very simple test to verify the *complete* flow of execution on an SSH terminal window:

1. Remove the "startup" line for spdMerlin from the "post-mount" script.

2. Execute the following command:

/jffs/scripts/spdmerlin forceupdate

3. Check the "post-mount" script to verify that the "startup" line has been added.

But, of course, you didn't do this simple test; otherwise, you would have seen confirmation of what I explained above.

Yes, to err is human, but making the same simple mistake twice within a short time (after being explicitly told about making the mistake the 1st time) is just sloppy work.

You claim to be a s/w developer, so you should know this by heart:
"When doing code reviews, always test & verify your assumptions as much as possible."

This is s/w engineering 101, simple as that.