Entware Okay to install entware update?

[scootertramp]

I am having an issue syslog-ng on my mesh nodes only. Twice now I have found syslog-ng not running and had to start it
on all three mesh nodes.

This is what I am seeing in the messages file.

Digging myself a bigger hole.
1) Tried rebooting node. ( syslog-ng stops after a period)
2) Attempted to reinstall scribe. ( same result)
3) unistall scribe,reboot and reinstall scribe. Went from bad to worst.
Now getting the following message on install.

 

[XIII]

Also Tailscale is downgraded (expected) and broken...

tailmon seems stuck on this:

error fetching current status: Failed to connect to local Tailscale daemon for /localapi/v0/status; not running? Error: dial unix /opt/var/run/tailscale/tailscaled.sock: connect: connection refused

EDIT: Fixed by running tailmon -setup and updating the Tailscale binaries again.

 

[scootertramp]

Digging myself a bigger hole.
1) Tried rebooting node. ( syslog-ng stops after a period)
2) Attempted to reinstall scribe. ( same result)
3) unistall scribe,reboot and reinstall scribe. Went from bad to worst.
Now getting the following message on install.

Ok, so I got scribe installed. Not sure how but there was an LD_LIBRARY_PATH set. I check my other two nodes and they do not have that set.
I just ran unset LD_LIBRARY_PATH and installed scribe. Now if it will just stay running.

 

[Viktor Jaep]

Entware only publishes updates 2 to 4 times per year. Today was the day.

From Russia, with love.

 

[Viktor Jaep]

This whole update process gives me Windows NT service pack vibes. Will be waiting for the weekend to update so I can handle all the fall-out in case the whole kit&kaboodle goes down.

 

[Stephen Harrington]

This whole update process gives me Windows NT service pack vibes. Will be waiting for the weekend to update so I can handle all the fall-out in case the whole kit&kaboodle goes down.

@Viktor Jaep

Glad I'm not the only one to remember NT service pack updates - the horror, the horror!

Ok, I did a quick Entware update last night and apart from the expected need to manually upgrade Tailscale and a quick re-install of Scribe as syslog-ng it has gone from version 4.7.1-2 -> 4.10.2-2, I noted the following with regard to your scripts after I had "stabilised everything" and looked closer.

I have vpnmon-r3, tailmon and rtrmon starting up from post-mount, with the following lines:

(sleep 30 && /jffs/scripts/vpnmon-r3.sh -screen -now) & # Added by vpnmon-r3

(sleep 40 && /jffs/scripts/tailmon.sh -screen -now) & # Added by tailmon

(sleep 50 && /jffs/scripts/rtrmon.sh -screen -now) & # Added manually

I think I may have tweaked the delay on a couple of them but it's so long ago I can't remember ... anyway all been working great prior to the latest Entware updates.

After the Entware updates, it seemed like none of them had run from post-mount, a "screen -ls" gave no results.

I did note the Entware "screen" utility had been updated from 4.9.1-2 -> 5.0.1-1, which may explain something?

I ran those post-mount lines manually from the command line and they appear to work ok, so it's only running from within post-mount at startup they are failing ... which has me a bit stumped?

Anyway, at that point I'd run out of my allowed upgrade window (thought it was going to be a quick and easy one - famous last words), so I did a quick "run away" and restored yesterday's backup from backupmon - how much do we love that? A lot! And back in business for now, but with that red "Entware packages -> 85p available" staring me in the face and triggering my OCD .

So when you have a play on the weekend maybe you can confirm my results and have a look at what may be causing it?

Cheers,

Stephen

 

[Viktor Jaep]

@Viktor Jaep

Glad I'm not the only one to remember NT service pack updates - the horror, the horror!

Ok, I did a quick Entware update last night and apart from the expected need to manually upgrade Tailscale and a quick re-install of Scribe as syslog-ng it has gone from version 4.7.1-2 -> 4.10.2-2, I noted the following with regard to your scripts after I had "stabilised everything" and looked closer.

I have vpnmon-r3, tailmon and rtrmon starting up from post-mount, with the following lines:

(sleep 30 && /jffs/scripts/vpnmon-r3.sh -screen -now) & # Added by vpnmon-r3

(sleep 40 && /jffs/scripts/tailmon.sh -screen -now) & # Added by tailmon

(sleep 50 && /jffs/scripts/rtrmon.sh -screen -now) & # Added manually

I think I may have tweaked the delay on a couple of them but it's so long ago I can't remember ... anyway all been working great prior to the latest Entware updates.

After the Entware updates, it seemed like none of them had run from post-mount, a "screen -ls" gave no results.

I did note the Entware "screen" utility had been updated from 4.9.1-2 -> 5.0.1-1, which may explain something?

I ran those post-mount lines manually from the command line and they appear to work ok, so it's only running from within post-mount at startup they are failing ... which has me a bit stumped?

Anyway, at that point I'd run out of my allowed upgrade window (thought it was going to be a quick and easy one - famous last words), so I did a quick "run away" and restored yesterday's backup from backupmon - how much do we love that? A lot! And back in business for now, but with that red "Entware packages -> 85p available" staring me in the face and triggering my OCD .

So when you have a play on the weekend maybe you can confirm my results and have a look at what may be causing it?

Cheers,

Stephen

Exactly what I was afraid of. Getting NT 4.0 SP3 BSOD flashbacks after reading all this! Lol. Thank you for testing the waters. I will definitely give it a go and test on Saturday. Will let you know what I find! So glad we can revert back to the last known good! Ha!!

 

[martinr]

Completely painless update on RT-AX68U (3004.388.11_beta1) running Diversion, Skynet and MerlinAU.

 

[alan6854321]

@Viktor Jaep - Hi there, I ran the Entware update yesterday and rebooted my router today.
Tailmon doesn't seem to have started up, no mention of it in syslog or in "ps | grep tailmon"

EDIT: I ran the "/jffs/scripts/tailmon.sh -screen &" command that I saw in post_mount and now it seems to be running.

 

[Viktor Jaep]

@Viktor Jaep - Hi there, I ran the Entware update yesterday and rebooted my router today.
Tailmon doesn't seem to have started up, no mention of it in syslog or in "ps | grep tailmon"

I think someone else mentioned they had to go into tailmon and force an update to the latest version to get it working again?

 

[alan6854321]

I think someone else mentioned they had to go into tailmon and force an update to the latest version to get it working again?

tailscale itself was running OK
I did the "opkg flag hold tailscale" thing a while ago to stop Entware updating it.

 

[alan6854321]

In my post-mount script, the spdMerlin command is right before tailmon and that started OK.

 

[Viktor Jaep]

EDIT: I ran the "/jffs/scripts/tailmon.sh -screen &" command that I saw in post_mount and now it seems to be running.

This seems to be similar behavior to what @Stephen Harrington was experiencing right above:

Entware - Okay to install entware update?

I am having an issue syslog-ng on my mesh nodes only. Twice now I have found syslog-ng not running and had to start it on all three mesh nodes. This is what I am seeing in the messages file. Digging myself a bigger hole. 1) Tried rebooting node. ( syslog-ng stops after a period) 2) Attempted...

www.snbforums.com

In my post-mount script, the spdMerlin command is right before tailmon and that started OK.

It might have something to do with the new version of "screen"? Oh boy. ;(

 

[jksmurf]

It might have something to do with the new version of "screen"? Oh boy. ;(

I don't use screen (except a long time back) and Tailscale works fine for me, after the entware update.

[EDIT] IIRC the steps I took, I updated entware, then saw the TS binary had dropped to the version in the new entware pkg, then I went into Tailmon and updated the TS binary from there and then all was OK after that. I did this on two separate networks.

 

[scootertramp]

I don't use screen (except a long time back) and Tailscale works fine for me, after the entware update.

I haven't seen any issues with using screen after the Entware update. Using screen for vpnmon-r3 and rtrmon.

On Main Node:
screen -dmS vpnmon  bash -c '/jffs/scripts/vpnmon-r3.sh ; exec sh'
or
On Mesh Nodes:
rmon7='rtrmon -screen 7 -now'

I am having issues with syslog-ng on my mesh nodes were it gets shutdown intermittently .
One shutdown that seems to be consistent is around midnight when all three mesh nodes have
syslog-ng stopping.

2026-04-09T00:00:04.808401-04:00 xt8-garage syslog-ng[14208]: syslog-ng shutting down; version='4.10.2'

I have been starting it back up in the morning.

2026-04-09T06:07:57.368947-04:00 xt8-garage syslog-ng[7247]: syslog-ng starting up; version='4.10.2'

 

[MegaMango]

If you're experiencing Entware binaries (jq, grep, find, curl, etc.) crashing with segfaults (signal 11) when triggered by the router's web UI (via service-event, start_apply.htm) but they work perfectly fine from SSH - the culprit is LD_LIBRARY_PATH.

On some firmware builds (particularly Gnuton and other third-party Merlin forks), the httpd process sets:

LD_LIBRARY_PATH=/lib:/usr/lib:/lib/aarch64

All child processes inherit this. When an Entware binary runs, the dynamic linker looks for shared libraries in /lib before /opt/lib, loading the firmware's incompatible libc instead of Entware's libc-2.27.so. This causes an immediate segfault.

You can confirm by checking httpd's environment and reproducing the crash from SSH:

cat /proc/$(pidof httpd)/environ | tr '\0' '\n' | grep LD_LIBRARY_PATH
# LD_LIBRARY_PATH=/lib:/usr/lib:/lib/aarch64

LD_LIBRARY_PATH=/lib:/usr/lib:/lib/aarch64 /opt/bin/jq --version
# Segmentation fault

LD_LIBRARY_PATH="" /opt/bin/jq --version
# jq-1.8.1

Why did this start happening now?
The LD_LIBRARY_PATH in httpd was always there on affected firmware, but it was a latent bug. The April 2 Entware update shipped rebuilt packages including grep 3.12, jq-full 1.8.1, coreutils 9.9, libpcre2 10.47, and notably binutils 2.45.1 (the toolchain itself). Packages rebuilt with the new toolchain may reference newer libc symbols or ABI features that only exist in Entware's libc - not in the firmware's older libc. The old binaries happened to use only symbols common to both, so loading the wrong libc was silently wrong but worked. After the update, it became fatal.

Fix for addon developers: Add `unset LD_LIBRARY_PATH` near the top of your script, before calling any Entware binaries. Entware binaries have the correct RPATH (/opt/lib) compiled in and don't need this variable. Unsetting it has no side effects - firmware binaries find their libraries through the default linker search path regardless.

Quick fix for users: If an addon hasn't been patched yet, you can add unset LD_LIBRARY_PATH to the top of /jffs/scripts/service-event (after #!/bin/sh) to fix it for all addons at once.

 

[Martinski]

If you're experiencing Entware binaries (jq, grep, find, curl, etc.) crashing with segfaults (signal 11) when triggered by the router's web UI (via service-event, start_apply.htm) but they work perfectly fine from SSH — the culprit is LD_LIBRARY_PATH.

On some firmware builds (particularly Gnuton and other third-party Merlin forks), the httpd process sets:

LD_LIBRARY_PATH=/lib:/usr/lib:/lib/aarch64

All child processes inherit this. When an Entware binary runs, the dynamic linker looks for shared libraries in /lib before /opt/lib, loading the firmware's incompatible libc instead of Entware's libc-2.27.so. This causes an immediate segfault.

Great catch!!

You can confirm by checking httpd's environment and reproducing the crash from SSH:

cat /proc/$(pidof httpd)/environ | tr '\0' '\n' | grep LD_LIBRARY_PATH
# LD_LIBRARY_PATH=/lib:/usr/lib:/lib/aarch64

LD_LIBRARY_PATH=/lib:/usr/lib:/lib/aarch64 /opt/bin/jq --version
# Segmentation fault

LD_LIBRARY_PATH="" /opt/bin/jq --version
# jq-1.8.1

Why did this start happening now?
The LD_LIBRARY_PATH in httpd was always there on affected firmware, but it was a latent bug. The April 2 Entware update shipped rebuilt packages including grep 3.12, jq-full 1.8.1, coreutils 9.9, libpcre2 10.47, and notably binutils 2.45.1 (the toolchain itself). Packages rebuilt with the new toolchain may reference newer libc symbols or ABI features that only exist in Entware's libc — not in the firmware's older libc. The old binaries happened to use only symbols common to both, so loading the wrong libc was silently wrong but worked. After the update, it became fatal.

Fix for addon developers: Add unset LD_LIBRARY_PATH near the top of your script, before calling any Entware binaries.

Agree with the fix or "workaround."

Entware binaries have the correct RPATH (/opt/lib) compiled in and don't need this variable.

Actually, that's no longer the case with the latest Entware updates, which caused the problem to come up now.

Starting with the most recent updates, the Entware developers modified the embedded library search path mechanism used by their latest ELF binaries. Now, the newest versions are using 'RUNPATH' (newer mechanism) instead of 'RPATH' (old/legacy method), which changed the order of precedence when searching for and loading dynamically linked shared libraries.

The library paths defined with RPATH have higher search priority than those defined via the LD_LIBRARY_PATH environment variable, which means that shared libraries found via RPATH always took precedence over the ones from LD_LIBRARY_PATH.

OTOH, the library paths now defined via RUNPATH are searched *AFTER* those defined via the LD_LIBRARY_PATH variable.

The end result is that once you have upgraded to the latest Entware binaries, users run the risk of loading the "wrong" libraries via LD_LIBRARY_PATH (when defined/inherited by the runtime environment) because the binaries now use the RUNPATH mechanism. And that's essentially the root cause that brought the problem to the forefront.

Sample screenshot showing previous "/opt/bin/jq" binary version using RPATH:

And now the latest "/opt/bin/jq" binary version using RUNPATH:

FYI.

 

[jacklul]

On my stock device the same crashing issue also happens when script is executed by the crond daemon (but not Entware's cron)

 

[Viktor Jaep]

Great catch!!


Agree with the fix or "workaround."


Actually, that's no longer the case with the latest Entware updates, which caused the problem to come up now.

Starting with the most recent updates, the Entware developers modified the embedded library search path mechanism used by their latest ELF binaries. Now, the newest versions are using 'RUNPATH' (newer mechanism) instead of 'RPATH' (old/legacy method), which changed the order of precedence when searching for and loading dynamically linked shared libraries.

The library paths defined with RPATH have higher search priority than those defined via the LD_LIBRARY_PATH environment variable, which means that shared libraries found via RPATH always took precedence over the ones from LD_LIBRARY_PATH.

OTOH, the library paths now defined via RUNPATH are searched *AFTER* those defined via the LD_LIBRARY_PATH variable.

The end result is that once you have upgraded to the latest Entware binaries, users run the risk of loading the "wrong" libraries via LD_LIBRARY_PATH (when defined/inherited by the runtime environment) because the binaries now use the RUNPATH mechanism. And that's essentially the root cause that brought the problem to the forefront.

Sample screenshot showing previous "/opt/bin/jq" binary version using RPATH:

View attachment 71150

And now the latest "/opt/bin/jq" binary version using RUNPATH:

View attachment 71151

FYI.

Thanks for diving into this further, @Martinski...

So to be clear, each of our scripts need to have LD_LIBRARY_PATH="" or unset LD_LIBRARY_PATH directly after the #!/bin/sh in order to fix this, or get it into compliance with whatever this change was?

What happens if this runs on an older installation of Entware? Or is this benign no matter what version you're on?

I also explicitly include a PATH statement near the top of each script. Does this have any effect on this change, or would it need to require any modification to help with compatibility?

export PATH="/sbin:/bin:/usr/sbin:/usr/bin:$PATH"

 

[ColinTaylor]

FYI If you're invoking Entware scripts either through the provided /opt/etc/init.d/rc.unslung mechanism, or (for interactive shells) having run /opt/etc/profile then they already contain an unset LD_LIBRARY_PATH command. This was the case even before this latest update.