Addon page suppresses Dnsmasq restart

[dave14305]

Diversion is - lets say - complicated with how certain events are executed. Which means I cannot have the web page issue a Dnsmasq restart.
It all has to run in precise order and only Diversion itself can handle that sequence properly.

We aren't privy to the scenarios you are working on, but I think it's achievable in some way. Once you hit Apply in the UI, your changes are written to custom_settings.txt. They are available to both the main diversion script and dnsmasq.postconf. Can they both read the same custom_settings.txt and can't dnsmasq.postconf modify dnsmasq.conf accordingly, assuming that diversion will complete its processing without fail? Could you not SIGHUP dnsmasq within Diversion instead of restarting it if Diversion updates a blocking list (for example)?

 

[thelonelycoder]

Uh oh. Something tells me your weekend is going to get eaten up by this. But we’ll benefit from the resulting update...somehow and eventually.
Go team!


Sent from my iPhone using Tapatalk

Yeah, I have been working on that damn WebUI for months now, half hear-ted. And now I find out that it has limitations I noticed all along but only now got to the bottom of it.

 

[thelonelycoder]

We aren't privy to the scenarios you are working on, but I think it's achievable in some way. Once you hit Apply in the UI, your changes are written to custom_settings.txt. They are available to both the main diversion script and dnsmasq.postconf. Can they both read the same custom_settings.txt and can't dnsmasq.postconf modify dnsmasq.conf accordingly, assuming that diversion will complete its processing without fail? Could you not SIGHUP dnsmasq within Diversion instead of restarting it if Diversion updates a blocking list (for example)?

It throws all the logic I've built in over board. post-conf.div is one hell of a file (I mean that in a positive way) that simplifies a lot with a single command. But building half of the diversion file logic into it to get this working is out of the question for me. I have to stop at some point.

Diversion is coded for SSH terminal, not a st*pid web page.

 

[dave14305]

It throws all the logic I've built in over board. post-conf.div is one hell of a file (I mean that in a positive way) that simplifies a lot with a single command. But building half of the diversion file logic into it to get this working is out of the question for me. I have to stop at some point.

Diversion is coded for SSH terminal, not a st*pid web page.

I want to give you a socially-distant man-hug.

 

[thelonelycoder]

I want to give you a socially-distant man-hug.

Thanks mate

 

[dave14305]

What if your service-event call is forked? It should clear the rc_service nvram immediately. Jack does this with one of his scripts. Then you can service restart_dnsmasq all you want.

if [ "$1" = "restart" ] && [ "$2" = "diversion" ]; then /opt/bin/diversion arg1 &; fi

 

[thelonelycoder]

What if your service-event call is forked? It should clear the rc_service nvram immediately. Jack does this with one of his scripts. Then you can service restart_dnsmasq all you want.

if [ "$1" = "restart" ] && [ "$2" = "diversion" ]; then /opt/bin/diversion arg1 &; fi;

As I said, it's more complicated than that. Users could have the idea of switching ad-blocking and logging off at the same time.
I can handle that but I need to orderly restart Dnsmasq (and maybe shut down pixelfckngserv-tls before) after writing the settings file.

 

[dave14305]

As I said, it's more complicated than that. Users could have the idea of switching ad-blocking and logging off at the same time.
I can handle that but I need to orderly restart Dnsmasq (and maybe shut down pixelfckngserv-tls before) after writing the settings file.

Unless you're adding multiple lines/conditions to service-event, the & will give you full freedom to do what you wanted originally (call service restart_dnsmasq from within Diversion). There's no reason to wait within service-event for it to finish since there's no real service to be started afterward. And completion of the service-event script doesn't impact anything else downstream in the GUI.

 

[Dabombber]

Other than forking to indicate you're done with the service-event part, you could add a workaround for skipped service events. Before version 384.15 I'd frequently get skipped events on boot, so I added this:

Spoiler: init-start

#!/bin/sh

# Monitor skipped events
tail -n0 -F '/tmp/syslog.log' | while read -r LINE; do
    if [ -z "${LINE##*"rc_service: skip the event:"*}" ] && [ -x '/jffs/scripts/service-event-skip' ]; then
        EVENT="${LINE#*"event: "}"
        EVENT="${EVENT%.}"
        if [ -z "${EVENT##*_*}" ]; then
            logger -t 'custom_script' "Running /jffs/scripts/service-event-skip (args: ${EVENT%%_*} ${EVENT#*_})"
            /jffs/scripts/service-event-skip "${EVENT%%_*}" "${EVENT#*_}" &
        else
            logger -t 'custom_script' "Running /jffs/scripts/service-event-skip (arg: $EVENT)"
            /jffs/scripts/service-event-skip "" "$EVENT" &
        fi
    fi
done &

Spoiler: service-event-skip

#!/bin/sh

if [ "$1" = 'start' ]; then
    case "$2" in
        'firewall')
            sleep 5
            service start_firewall
        ;;
        'dhcp6c')
            sleep 30
            if ! pidof odhcp6c &>/dev/null; then
                service start_dhcp6c
            fi
        ;;
    esac
fi

 

[SomeWhereOverTheRainBow]

Other than forking to indicate you're done with the service-event part, you could add a workaround for skipped service events. Before version 384.15 I'd frequently get skipped events on boot, so I added this:

Spoiler: init-start

#!/bin/sh

# Monitor skipped events
tail -n0 -F '/tmp/syslog.log' | while read -r LINE; do
    if [ -z "${LINE##*"rc_service: skip the event:"*}" ] && [ -x '/jffs/scripts/service-event-skip' ]; then
        EVENT="${LINE#*"event: "}"
        EVENT="${EVENT%.}"
        if [ -z "${EVENT##*_*}" ]; then
            logger -t 'custom_script' "Running /jffs/scripts/service-event-skip (args: ${EVENT%%_*} ${EVENT#*_})"
            /jffs/scripts/service-event-skip "${EVENT%%_*}" "${EVENT#*_}" &
        else
            logger -t 'custom_script' "Running /jffs/scripts/service-event-skip (arg: $EVENT)"
            /jffs/scripts/service-event-skip "" "$EVENT" &
        fi
    fi
done &

Spoiler: service-event-skip

#!/bin/sh

if [ "$1" = 'start' ]; then
    case "$2" in
        'firewall')
            sleep 5
            service start_firewall
        ;;
        'dhcp6c')
            sleep 30
            if ! pidof odhcp6c &>/dev/null; then
                service start_dhcp6c
            fi
        ;;
    esac
fi

That is a wicked hack man! How did you think this one up?

 

[Dabombber]

That is a wicked hack man! How did you think this one up?

Out of necessity mostly, not having the firewall or IPv6 working after a reboot was kinda... bad. It'd be nice if there was a better way then reading the log, but as mentioned the event stuff is all closed source now.

 

[SomeWhereOverTheRainBow]

Out of necessity mostly, not having the firewall or IPv6 working after a reboot was kinda... bad. It'd be nice if there was a better way then reading the log, but as mentioned the event stuff is all closed source now.

It would be nice to have a watch dog for all those sneak services.

 

[thelonelycoder]

Sorry for being grumpy about that find in this thread.

Further testing will show if this always works. But sending the Dnsmasq restart to a background file and immediately restart Dnsmasq there appears to work.

 

[thelonelycoder]

This discussion and the solution I now have had a good side effect. I was aware for a long time that pixelserv-tls would not come up or unexpectedly start, along with the very seldom non-write of the changed Dnsmasq config file.

I was finally able to trace it down due to the hints given by @john9527 and @dave14305: To that race condition when at least two services ares being restarted simultaneously.
Dnsmasq would be delayed or skipped if pixelserv-tls restarts because the virtual IP comes up or down, triggering the routers avahi-daemon and lldpd service. These both can lead to Dnsmasq restart being skipped or pixelserv-tls remaining down.

 

[RMerlin]

But after 1 or 0 secs "spinning wait" it should still do the job.

The wait value defined on the webui is unrelated to the wait period used by the rc_* functions. The webui value only controls the spinner display. The wait period itself is hardcoded in libhared. It used to be 15 secs (which I had increased to 30 secs), but Asus decided a few years ago to close the sources of that code, so it went back to 15 secs (assuming they haven't changed it since), and can no longer be adjusted.

 

[dave14305]

I’ve been trying to come up with a succinct explanation of the limitations and workarounds for calling a service command from within the service-event or service-event-end scripts.

Once we press apply in the GUI, httpd triggers the service specified in action_script. The rc_service and rc_service_pid nvram variables get populated with the requested service from action_script and httpd’s pid, respectively.

rc will trigger the service-event script. Until the service-event script ends, the rc_service nvram is still populated with the original values above. Any additional service calls will wait for those nvram vars to clear before “accepting” the service command. If the timeout is reached, we get the skipped log message because the new service command is waiting for the current service-event to end. But it is paused waiting for the new service command to timeout. A form of deadlock with a safety timeout.

So it is very important to finish the service-event script ASAP so that the rc_service nvram vars get cleared of httpd pid and the action_script service name. By forking the custom Addon script call within service-event, the service-event script will end and the forked script can successfully call as many service commands it wants to.

I believe I have these points correct, but would appreciate another set of eyes or the voices of experience. And obviously I’m still struggling with the “succinct” part.

 

[RMerlin]

If you want to study how the notification system used to work (it's probably still fairly similar today), you can review the code pre-closing:

https://github.com/RMerl/asuswrt-me...7b3bffe/release/src/router/shared/notify_rc.c

 

[dave14305]

If you want to study how the notification system used to work (it's probably still fairly similar today), you can review the code pre-closing:

https://github.com/RMerl/asuswrt-me...7b3bffe/release/src/router/shared/notify_rc.c

Yes, I used John’s repo to figure out where the skipped messages were coming from. And since the new code is closed source, no chance of correcting the misspelled “waitting” log message.

 

[thelonelycoder]

I now send my service-event triggered script directly to the background. This works flawless, the event is done in a fraction of a second.
Then I adjusted the order of events to not cancel other service calls out:
1. Write changed Diversion config file, which also (re)sets states in custom_settings.txt
2. Restart Dnsmasq, it sets cron jobs, Diversion service states and more
3. Bring up or down the virtual interface(s)
4. Start or stop pixelserv-tls

So far so good

 

[thelonelycoder]

@john9527 and anyone who has input.

On Johns fork, the standard Apply button popup just keeps spinning after the set timeout, without returning to the page. Has anyone else noticed this?
Force reloading the page shows the settings have been applied, so there seems to be an issue with killing the popup.

I'm loading the standard js files:

/user/diver
/state.js
/general.js
/popup.js
/help.js

The Browser console shows no error.