Entware Where is Entware started upon reboot?

[bibikalka]

That's because Entware starts services in numerical order that have an S* start file in /opt/etc/init.d/.
After amtm mounts the /opt folder it kicks off /opt/etc/init.d/rc.unslung which runs the above.

Alright - this rabbit hole goes very deep ...

I watched things over the week - and warm reboots are a mess, things seem to be launched in weird order or when they should not be. For cold reboots the boot sequence seems as expected.

Having said that about warm reboots, I've been warm rebooting daily for a year, and overall despite all the randomness it seems to work reasonably OK, and prevents other issues that accumulate over days of uptime. It's basically - pick your poison.

To address my specific issue of "already in use" it seems this fix helps in mount-entware.mod:

                (sleep 60 && service restart_dnsmasq) &

My best guess is that a couple of dnsmasq restarts were sometimes happening nearly simultaneously, and that was messing things up since there are no locks on those restarts.

Update: Here is a random warm reboot, with the 60 seconds sleep. The last br0 message is the that service restart_dnsmasq command after the 60 seconds sleep. Something else was restarting dnsmasq before that.

# egrep -a 'Starting Entware|192.168.1.16' messages |grep -v separate
Oct  7 09:40:47 Entware: Starting Entware and Diversion services on /tmp/mnt/ac86u
Oct  7 09:41:00 RT-AC86U-9988 avahi-daemon[6130]: Registering new address record for 192.168.1.16 on br0.IPv4.
Oct  7 09:41:00 RT-AC86U-9988 Diversion: created br0:ad_blocking_excl for 192.168.1.16
Oct  7 09:41:05 RT-AC86U-9988 Diversion: created br0:ad_blocking_excl for 192.168.1.16
Oct  7 09:41:49 RT-AC86U-9988 Diversion: created br0:ad_blocking_excl for 192.168.1.16

 

[bibikalka]

Update:

I have added a couple of sleep commands, and things seem good now. No more error messages. I feel it's important to give a few seconds after Entware creates the links and before rc.unslung script kicks in. It seems there is a prior dnsmasq restart in progress, that completes upon Entware mount. The other 60 second sleep is sort of just to space things in time a bit.

Here are the sleep commands:

admin@RT-AC86U-9988:/jffs/addons/amtm# more mount-entware.mod
#!/bin/sh
#bof

mount_entware(){
        if [ -f "${opkgFile%/opkg}/diversion" ]; then
                logger -t Entware "Starting Entware and Diversion services on $1"
                ln -nsf "${opkgFile%/bin/opkg}" /tmp/opt
                sleep 7
                /opt/etc/init.d/rc.unslung start $0
                (sleep 60 && service restart_dnsmasq) &
#               service restart_dnsmasq
        else
                logger -t Entware "Starting Entware services on $1"
                ln -nsf "${opkgFile%/bin/opkg}" /tmp/opt
                /opt/etc/init.d/rc.unslung start $0
        fi
}

Here is my recent history of warm reboots, sometimes some log lines are eaten by Scribe as it restarts, so it's not always consistent:

#egrep -a 'Starting Entware|192.168.1.16' /opt/var/log/messages |grep -v separate|grep -v mDNS |grep -v DHCP
Oct 12 04:06:42 Entware: Starting Entware and Diversion services on /tmp/mnt/ac86u
Oct 12 04:07:01 RT-AC86U-9988 avahi-daemon[5929]: Registering new address record for 192.168.1.16 on br0.IPv4.
Oct 12 04:07:01 RT-AC86U-9988 Diversion: created br0:ad_blocking_excl for 192.168.1.16
Oct 12 04:07:52 RT-AC86U-9988 Diversion: created br0:ad_blocking_excl for 192.168.1.16
Oct 12 20:25:04 RT-AC86U-9988 Diversion: created br0:ad_blocking_excl for 192.168.1.16
Oct 13 04:06:42 Entware: Starting Entware and Diversion services on /tmp/mnt/ac86u
Oct 13 04:06:43 avahi-daemon[4178]: Registering new address record for 192.168.1.16 on br0.IPv4.
Oct 13 04:06:43 Diversion: created br0:ad_blocking_excl for 192.168.1.16
Oct 13 04:06:54 RT-AC86U-9988 avahi-daemon[6157]: Registering new address record for 192.168.1.16 on br0.IPv4.
Oct 13 04:07:00 RT-AC86U-9988 Diversion: created br0:ad_blocking_excl for 192.168.1.16
Oct 13 04:07:52 RT-AC86U-9988 Diversion: created br0:ad_blocking_excl for 192.168.1.16
Oct 13 14:25:04 RT-AC86U-9988 Diversion: created br0:ad_blocking_excl for 192.168.1.16
Oct 14 04:06:33 Entware: Starting Entware and Diversion services on /tmp/mnt/ac86u
Oct 14 04:06:39 RT-AC86U-9988 avahi-daemon[2904]: Registering new address record for 192.168.1.16 on br0.IPv4.
Oct 14 04:06:39 RT-AC86U-9988 Diversion: created br0:ad_blocking_excl for 192.168.1.16
Oct 14 05:25:04 RT-AC86U-9988 Diversion: created br0:ad_blocking_excl for 192.168.1.16

 

[Ripshod]

Great! You've used up 2 weeks of your life chasing an error that no-one else has rather than just reset the router.
This rabbit hole is only as deep as you could dig it.

 

[bibikalka]

Great! You've used up 2 weeks of your life chasing an error that no-one else has rather than just reset the router.
This rabbit hole is only as deep as you could dig it.

Oh, it's been more than that!

But on and off - and I learnt a few things along the way too.

I prefer to auto-reboot the router daily - few people do that. It solves some issues, but creates others. The stock solution is to fully power off the device - but I don't like that one. If not auto-rebooting, I had to do the manual power off about weekly after it'd hung up in some way. So pick your poison.

As such - I am not sure the reset would have helped, given that daily reboots are not the standard practice, and the boot sequence becomes a lot more unpredictable. I think there is a lot more timing dependence during the boot that people give credit for.

 

[Ripshod]

I'd spend my time trying to find out why the reboots became necessary in your mind and fix the problem, rather than patching the damage done by daily reboots. Did you do any real diagnosis first?

 

[bibikalka]

I'd spend my time trying to find out why the reboots became necessary in your mind and fix the problem, rather than patching the damage done by daily reboots. Did you do any real diagnosis first?

Yeah, I looked at that a bit - at first I did not reboot for a while, and had to manually reset it from time to time when it became unresponsive. One of the issues is max pid - [echo 4194304 > /proc/sys/kernel/pid_max]

The other issue is the the dcd translation faults, due to parental control features in the proprietary Asus code. This one mostly has no impact, but occasionally messes things up.

So nightly reboots with my quick check in the morning are far more preferred to alternative issues.

These routers still have tons of Asus footprint even when Merlin is loaded. So whatever bugs are there - they do come up. This ain't exactly libreboot CFE/bootloader with a fully tested Linux on top!