RTRMON RTRMON v2.4.1 [2026-Apr-14] - Monitor your Router's Health (New: Wireguard, AMTM, Network Conn/Bandwidth/Diag + Port Scanner + Speedtest)

[dave14305]

It seems the environment variables for this new version of screen that came with the latest round of Entware updates is not optimal, and prevents scripts that call screen from being able to start. Do you think this should be addressed with the Screen authors, or is it best to just clutter up the POST-MOUNT with additional code to provide this workaround? Or is there perhaps a better way?

How would I recreate the problem? I installed RTRMON with screen v5.0.1 but don't see how to create the failure state.

 

[Viktor Jaep]

How would I recreate the problem? I installed RTRMON with screen v5.0.1 but don't see how to create the failure state.

You could add this to your post-mount:

(sleep 30 && /jffs/scripts/rtrmon.sh -screen) &

And reboot.

Expected behavior is that it won't start up in a screen session unless you add those new variables to the top of the post-mount.

 

[dave14305]

You could add this to your post-mount:

(sleep 30 && /jffs/scripts/rtrmon.sh -screen) &

And reboot.

Expected behavior is that it won't start up in a screen session unless you add those new variables to the top of the post-mount.

That's strange. I've been trying to see if there's a cleaner way by invoking screen in an /opt/etc/init.d/S99rtrmon-screen kind of script, to avoid a kludgey "sleep 30", but the variables still seem to require explicit definition.

#!/bin/sh

PROCS=screen
ARGS="-dmS rtrmon /jffs/scripts/rtrmon.sh -monitor"
PREARGS=
PRECMD="export SCREENDIR=/root/.screen HOME=/root"
POSTCMD=
DESC=$PROCS
ENABLED=yes

. /opt/etc/init.d/rc.func

I don't know how this worked or didn't work on the previous versions of Entware and screen. I don't see many obvious changes to the variable handling in GNU screen to explain it specific to this tool.

 

[Viktor Jaep]

That's strange. I've been trying to see if there's a cleaner way by invoking screen in an /opt/etc/init.d/S99rtrmon-screen kind of script, to avoid a kludgey "sleep 30", but the variables still seem to require explicit definition.

#!/bin/sh

PROCS=screen
ARGS="-dmS rtrmon /jffs/scripts/rtrmon.sh -monitor"
PREARGS=
PRECMD="export SCREENDIR=/root/.screen HOME=/root"
POSTCMD=
DESC=$PROCS
ENABLED=yes

. /opt/etc/init.d/rc.func

I don't know how this worked or didn't work on the previous versions of Entware and screen. I don't see many obvious changes to the variable handling in GNU screen to explain it specific to this tool.

On the previous version of screen, that single command in the post-mount would successfully launch the script inside a screen session in the background.

 

[Martinski]

You could add this to your post-mount:

(sleep 30 && /jffs/scripts/rtrmon.sh -screen) &

And reboot.

Expected behavior is that it won't start up in a screen session unless you add those new variables to the top of the post-mount.

I've been following the reports WRT the issues when the script is launched from post-mount with the -screen parameter and today over launch, it occurred to me that the problem might be related to executing the script in non-interactive mode. So I made a few changes, ran 2 tests, and it's working fine on my test router. However, I did not test it by actually rebooting the router; I simply ran the script with the -screen parameter from service-event to simulate a non-interactive mode session.

If you have not yet resolved the problem, I just submitted a PR with my changes, so if you have time, please test this latest version on your router.

Good luck!!

 

[Viktor Jaep]

I've been following the reports WRT the issues when the script is launched from post-mount with the -screen parameter and today over launch, it occurred to me that the problem might be related to executing the script in non-interactive mode. So I made a few changes, ran 2 tests, and it's working fine on my test router. However, I did not test it by actually rebooting the router; I simply ran the script with the -screen parameter from service-event to simulate a non-interactive mode session.

If you have not yet resolved the problem, I just submitted a PR with my changes, so if you have time, please test this latest version on your router.

Good luck!!

That is some serious magic with all the non-interactive TTY stuff, @Martinski! I am going to need to pick this apart to understand how this all works.

So as a first test, I removed the HOME and SCREENDIR declarations from the post-mount file, and left everything else the same. Then, in the script, I just added:

##-------------------------------------##
## Added by Martinski W. [2026-Apr-13] ##
##-------------------------------------##
[ "$HOME" != "/root" ] && export HOME="/root"
export SCREENDIR="${HOME}/.screen"

And believe it or not, it actually started up after a reboot! My second test script that did not have this addition did not start up. So that seems to prove it. I was wondering if it was possible to move this into the script itself if necessary, just to keep that post-mount clean.

 

[Martinski]

That is some serious magic with all the non-interactive TTY stuff, @Martinski! I am going to need to pick this apart to understand how this all works.

So as a first test, I removed the HOME and SCREENDIR declarations from the post-mount file, and left everything else the same. Then, in the script, I just added:

##-------------------------------------##
## Added by Martinski W. [2026-Apr-13] ##
##-------------------------------------##
[ "$HOME" != "/root" ] && export HOME="/root"
export SCREENDIR="${HOME}/.screen"

And believe it or not, it actually started up after a reboot! My second test script that did not have this addition did not start up. So that seems to prove it. I was wondering if it was possible to move this into the script itself if necessary, just to keep that post-mount clean.

Yes, that's my recommendation. Make the changes to export the required environment variables inside each script that calls the Entware screen utility. That way, you avoid writing code that would check and modify the post-mount script (if needed), especially since not all scripts call the screen tool.

Glad things worked out in the end.

 

[Viktor Jaep]

Minor patch to make it compliant with the new version of screen. Thank you for your eyes on this, @Martinski, @dave14305 and @Stephen Harrington! Will be rolling this out across my other scripts here shortly since most depend on screen.

What's new?
v2.4.1 - (April 14, 2026)
- MINOR: Diving into why the new version of SCREEN (v5.0.1) didn't want to start from a script in the post-mount, found that some SCREEN environment variables weren't being set. Thanks to some input from @Martinski, these variables can be included in the script, instead of adding these to the top of the post-mount.

Download link (or autoupdate directly from within AMTM or RTRMON):

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/RTRMON/main/rtrmon.sh" -o "/jffs/scripts/rtrmon.sh" && chmod 755 "/jffs/scripts/rtrmon.sh"

 

[visortgw]

Minor patch to make it compliant with the new version of screen. Thank you for your eyes on this, @Martinski, @dave14305 and @Stephen Harrington! Will be rolling this out across my other scripts here shortly since most depend on screen.

What's new?
v2.4.1 - (April 14, 2026)
- MINOR: Diving into why the new version of SCREEN (v5.0.1) didn't want to start from a script in the post-mount, found that some SCREEN environment variables weren't being set. Thanks to some input from @Martinski, these variables can be included in the script, instead of adding these to the top of the post-mount.

Download link (or autoupdate directly from within AMTM or RTRMON):

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/RTRMON/main/rtrmon.sh" -o "/jffs/scripts/rtrmon.sh" && chmod 755 "/jffs/scripts/rtrmon.sh"

amtm autoupdate works perfectly!