jffs/scripts/services-start not executed after reboot

[Ribboa]

Hi everyone,

my router: RT-AC87U
Firmware: 384.5

my services-start script is not executed after a reboot.

I put this code at the top of each script in /jffs/scripts in order to verify:

DATE=$(date +"%Y-%m-%d-%H%M%S")
mkdir -p /tmp/logs
touch /tmp/logs/$DATE-services-start

this is the content of /tmp/logs/:

drwxrwxrwx    2 admin    root           140 Jul  5 22:12 .
drwxrwxrwx   15 admin    root          1060 Jul  5 22:18 ..
-rw-rw-rw-    1 admin    root             0 Feb 14  2017 2017-02-14-010035-services-start
-rw-rw-rw-    1 admin    root             0 Feb 14  2017 2017-02-14-010036-firewall-start
-rw-rw-rw-    1 admin    root             0 Jul  5 22:12 2018-07-05-221221-firewall-start
-rw-rw-rw-    1 admin    root             0 Jul  5 22:12 2018-07-05-221237-post-mount
-rw-rw-rw-    1 admin    root             0 Jul  5 22:12 2018-07-05-221244-post-mount

So anyone have an idea what's wrong? I wonder what these old entries (14th Feb 2017) are all about as /tmp is tmpfs and should be only stored in RAM, right? Any ideas what's going wrong?

Kind regards
Ribboa

 

[kfp]

Execute bit is not set

chmod +x <script name>

Edit: those are not the scripts themselves so of course execute bit is not set. I should learn to read.

 

[ColinTaylor]

So anyone have an idea what's wrong? I wonder what these old entries (14th Feb 2017) are all about as /tmp is tmpfs and should be only stored in RAM, right? Any ideas what's going wrong?

I suspect the script is actually running. The file will have that date/time because the script runs before NTP has had a chance to set the date/time. So the timestamp is the firmware's default.

 

[Ribboa]

I suspect the script is actually running. The file will have that date/time because the script runs before NTP has had a chance to set the date/time. So the timestamp is the firmware's default.

You are right. Obviously the script has been started too early and therefore the timestamp is "broken" and somehow my services are not started. Adding a sleep 60 at the beginning of the services-start script solved the issue for me. I just wonder why I have this problems and others seem not to have it.

 

[Adamm]

I just wonder why I have this problems and others seem not to have it.

Just a minor inconvenience, easy to work around it

retry=1
while [ "$(nvram get ntp_ready)" = "0" ] && [ "$retry" -lt "300" ]; do
    retry=$((retry+1))
    sleep 1
done
if [ "$retry" -ge "300" ]; then logger -st Skynet "[ERROR] NTP Failed To Start After 5 Minutes - Please Fix Immediately!"; exit 1; fi

 

[skeal]

You are right. Obviously the script has been started too early and therefore the timestamp is "broken" and somehow my services are not started. Adding a sleep 60 at the beginning of the services-start script solved the issue for me. I just wonder why I have this problems and others seem not to have it.

Do you use FreshJR_QOS in particular the fast version? If this is the case it really messes with your startup. You may use the compatible version and it won't mess with the normal startup.

 

[Ribboa]

Do you use FreshJR_QOS in particular the fast version? If this is the case it really messes with your startup. You may use the compatible version and it won't mess with the normal startup.

No, I don't use it.

 

[Ribboa]

Just a minor inconvenience, easy to work around it

retry=1
while [ "$(nvram get ntp_ready)" = "0" ] && [ "$retry" -lt "300" ]; do
    retry=$((retry+1))
    sleep 1
done
if [ "$retry" -ge "300" ]; then logger -st Skynet "[ERROR] NTP Failed To Start After 5 Minutes - Please Fix Immediately!"; exit 1; fi

Thanks, that ensures that the script wait for ntp to be ready, but unfortunately it's still too early to start nginx. I do not find any hint in the logs.

 

[Ribboa]

Ok, I found something:

Jul  6 22:37:32 admin: Could not start Entware

This is logged by services-start:

RC='/opt/etc/init.d/rc.unslung'

i=30
until [ -x "$RC" ] ; do
  i=$(($i-1))
  if [ "$i" -lt 1 ] ; then
    logger "Could not start Entware"
    exit
  fi
  sleep 1
done
$RC start

And later on:

Jul  6 22:37:36 usb: USB ext2 fs at /dev/sda1 mounted on /tmp/mnt/entware.
Jul  6 22:37:36 custom_script: Running /jffs/scripts/post-mount (args: /tmp/mnt/entware ) - max timeout = 120s

I am not a bash pro, but I guess the scripts waits for the existence of /opt/etc/init.d/rc.unslung and logs "Could not start Entware" if it couldn't be found after 30 seconds.

The post-mount script is executed 4 seconds after "Could not start Entware" has been logged.

My conclusion: The 30 seconds are not enough time to wait for /opt being mounted. I will increase it to 60 seconds. In my opinion this should be increased in https://github.com/RMerl/asuswrt-merlin/blob/master/release/src/router/others/entware-setup.sh as well.

Edit: With i=60 it works like a charm ;-)

 

[Jack Yaz]

Ok, I found something:

Jul  6 22:37:32 admin: Could not start Entware

This is logged by services-start:

RC='/opt/etc/init.d/rc.unslung'

i=30
until [ -x "$RC" ] ; do
  i=$(($i-1))
  if [ "$i" -lt 1 ] ; then
    logger "Could not start Entware"
    exit
  fi
  sleep 1
done
$RC start

And later on:

Jul  6 22:37:36 usb: USB ext2 fs at /dev/sda1 mounted on /tmp/mnt/entware.
Jul  6 22:37:36 custom_script: Running /jffs/scripts/post-mount (args: /tmp/mnt/entware ) - max timeout = 120s

I am not a bash pro, but I guess the scripts waits for the existence of /opt/etc/init.d/rc.unslung and logs "Could not start Entware" if it couldn't be found after 30 seconds.

The post-mount script is executed 4 seconds after "Could not start Entware" has been logged.

My conclusion: The 30 seconds are not enough time to wait for /opt being mounted. I will increase it to 60 seconds. In my opinion this should be increased in https://github.com/RMerl/asuswrt-merlin/blob/master/release/src/router/others/entware-setup.sh as well.

Edit: With i=60 it works like a charm ;-)

I start Entware in post-mount, so if the mounted drive is the entware drive, run rc.unslung. Seems much cleaner than a timeout/looping check

if [ "$1" = "/tmp/mnt/entware" ] ; then
    ln -nsf $1/entware /tmp/opt
    logger "$0:" "Running rc.unslung to start Entware services..."
    /opt/etc/init.d/rc.unslung start
fi

 

[johnathonm]

Jack,

Question, if my entware folder is located in /tmp/mnt/sda1/entware, how would I need to modify this script?

Thanks,
J

 

[thelonelycoder]

Jack,

Question, if my entware folder is located in /tmp/mnt/sda1/entware, how would I need to modify this script?

Thanks,
J

This'll work for you.

if [ "$1" = "/tmp/mnt/sda1" ] ; then
    ln -nsf $1/entware /tmp/opt
    logger "$0:" "Running rc.unslung to start Entware services..."
    /opt/etc/init.d/rc.unslung start
fi

 

[Jack Yaz]

I was replying but beaten to it ;-)

 

[johnathonm]

This'll work for you.

if [ "$1" = "/tmp/mnt/sda1" ] ; then
    ln -nsf $1/entware /tmp/opt
    logger "$0:" "Running rc.unslung to start Entware services..."
    /opt/etc/init.d/rc.unslung start
fi

You rock LC, and I love your programs. The use of a menu driven system makes life so so much easier. I really can't wait to see what you come up with next. Also, thank you for linking the lists between skynet and AB. That was awesome.

 

[johnathonm]

Lonelycoder,

Is this something I can build into your section of DO NOT EDIT?

J

 

[thelonelycoder]

Lonelycoder,

Is this something I can build into your section of DO NOT EDIT?

J

Yes and no. Unless you know what you're doing I would leave things as they are. rc.unslung is started through the services-start in AB-Solution 3. AB 4 will have a totally different mechanism to start services.

 

[johnathonm]

Yes and no. Unless you know what you're doing I would leave things as they are. rc.unslung is started through the services-start in AB-Solution 3. AB 4 will have a totally different mechanism to start services.

I will follow your lead on this one.