Script disappeared

[Woody1]

Today I was troubleshooting a problem on my RT-AC68P with v384.15 and I discovered that my 'services-start' script was missing. I looked back at my backups and it appears that it went away sometime within the last year. I was using 'services-start' to execute a python script that checked on reboot to make sure I got a good external IP address from my AT&T gateway device.

I see that some new scripts were added, e.g, 'service-event'.

I have installed Skynet and diversion, both of which manipulated various scripts, but I would not have expected that either of them would have deleted 'services-start'. Did something happen in some previous update that would have caused this?

 

[L&LD]

Yes, read the changelogs for the last few firmware and you'll find the changes and reasons for your issue.

 

[dave14305]

Yes, read the changelogs for the last few firmware and you'll find the changes and reasons for your issue.

I've never seen a script disappear, unless /jffs was formatted. Do you have something specific in mind from the changelog?

 

[L&LD]

I may be wrong (again), but I seem to be remembering something about the start scripts was changed?

 

[Martineau]

I've never seen a script disappear, unless /jffs was formatted. Do you have something specific in mind from the changelog?

see this

 

[Woody1]

So, it looks like a Diversion installation or update caused this. The developer for Diversion said

For all the funky other stuff that some people paste into the jffs/scripts directory I have no patience to merge when coming from AB-Solution 3.11.x.

So, he's not patient with whatever "funky stuff" "some people" put into their scripts. Apparently, his view is that those scripts are there for his use only and people should just expect that he'll wipe them out if they get in his way. Quite an attitude. Seems to me that the neighborly thing is to try to "do no harm" when installing new software.

 

[Woody1]

After some more research, it looks like the Diversion installation script considers "/opt/etc/init.d/rc.unslung" to be an obsolete way to launch Entware and removes services-start if it detects that bit of code. Can somebody explain to me why that's obsolete and how to correctly launch Entware?

 

[elorimer]

After some more research, it looks like the Diversion installation script considers "/opt/etc/init.d/rc.unslung" to be an obsolete way to launch Entware and removes services-start if it detects that bit of code. Can somebody explain to me why that's obsolete and how to correctly launch Entware?

It's started through postmount, so as not to start before the USB drive is mounted. Then it calls mount-entware.div, which calls rc.unslung.

 

[thelonelycoder]

So, it looks like a Diversion installation or update caused this. The developer for Diversion said



So, he's not patient with whatever "funky stuff" "some people" put into their scripts. Apparently, his view is that those scripts are there for his use only and people should just expect that he'll wipe them out if they get in his way. Quite an attitude. Seems to me that the neighborly thing is to try to "do no harm" when installing new software.

I have had very valid reasons two years ago when I made that choice and don't regret it.

 

[Woody1]

It's started through postmount, so as not to start before the USB drive is mounted. Then it calls mount-entware.div, which calls rc.unslung.

OK, I see. This looks like a configuration that is specifically set up by Diversion. I assume that if you don't install Diversion, rc.unslung is still called directly from services-start? Or is this part of some change to the way Entware is normally installed?

 

[thelonelycoder]

OK, I see. This looks like a configuration that is specifically set up by Diversion. I assume that if you don't install Diversion, rc.unslung is still called directly from services-start? Or is this part of some change to the way Entware is normally installed?

The official Asuswrt-Merlin way to install Entware is trough amtm which uses the same method as Diversion, naturally.

 

[Woody1]

The official Asuswrt-Merlin way to install Entware is trough amtm which uses the same method as Diversion, naturally.

OK, thanks for the clarification. I haven't used amtm until now. I wasn't aware that it's now the official way to manage add-on applications. I have various scripts that I'll need to bring up to date to make sure they're compatible with this way of doing things.

 

[thelonelycoder]

OK, thanks for the clarification. I haven't used amtm until now. I wasn't aware that it's now the official way to manage add-on applications. I have various scripts that I'll need to bring up to date to make sure they're compatible with this way of doing things.

Starting with Asuswrt-Merlin 384.15, amtm is included in the firmware. The old entware-setup.sh script was replaced with amtm since my method uses a better and more reliable way of starting Entware.
You can still place things into /jffs/scripts/services-start as long as it does not comtain entries from the old entware installer.
But since you use perl, I presume it requires Entware. Add your code to the post-mount script, just after the Diversion or amtm one-liner. It will not be removed by either of my scripts.

 

[elorimer]

OK, I see. This looks like a configuration that is specifically set up by Diversion. I assume that if you don't install Diversion, rc.unslung is still called directly from services-start? Or is this part of some change to the way Entware is normally installed?

No. The older script is toast and the firmware now installs entware through amtm. It gets started from post-mount and now handles both diversion and non-diversion cases. Amtm is the new normal and it is way better. Among other things it is part of a standardized way the add-ons are written and are managed. In truth this change was made years ago.

Services-start is still used. Here's mine:

#!/bin/sh
/jffs/scripts/uiDivStats startup # uiDivStats
/jffs/scripts/uiScribe startup # uiScribe
/jffs/scripts/connmon startup # connmon
/jffs/scripts/spdmerlin startup # spdMerlin
cru a root_servers  "12 4 * * * curl -o \/opt\/var\/lib\/unbound\/root\.hints https://www.internic.net/domain/named.cache"    # unbound_manager
/jffs/addons/unbound/unbound_rpz.sh startup # Unbound_RPZ.sh

Note all these are added by various add-ons (one line per) and have a common way of being added and deleted when an addon is uninstalled. If you add something, it would be smart to follow the same convention and call your own script with one line here.

 

[Woody1]

OK, I guess I've had everything running on auto-pilot for a long time and I haven't paid attention to these developments. I'll try to get with the program. Thanks for the explanations.

One question: when I launch Diversion, it complains:

df: /mnt/AsusUSB/entware.arm: can't find mount point

I see that I have Entware installed in '/mnt/AsusUSB/entware' not '/mnt/AsusUSB/entware.arm'. Does Diversion always expect it to be in 'entware.arm' or is it picking up this info from somewhere in my scripts?