NTP boot watchdog script

[Jack Yaz]

Do you find that NTP will often taken longer than 5 minutes to sync, causing some addons to fail to start? If so, please read on for a workaround!

NTP "aggressive" syncing on boot while I thrash out a proper fix
Create /jffs/scripts/ntpbootwatchdog.sh

#!/bin/sh
if [ "$(nvram get ntp_ready)" -eq 1 ]; then
    /usr/bin/logger -st "ntpbootwatchdog" "NTP is synced, exiting"
else
    /usr/bin/logger -st "ntpbootwatchdog" "NTP boot watchdog started..."
    ntptimer=0
    while [ "$(nvram get ntp_ready)" -eq 0 ] && [ "$ntptimer" -lt 600 ]; do
        if [ "$ntptimer" -ne 0 ]; then
            /usr/bin/logger -st "ntpbootwatchdog" "Still waiting for NTP to sync..."
        fi
        killall ntp
        killall ntpd
        service restart_ntpd
        ntptimer=$((ntptimer+30))
        sleep 30
    done
    
    if [ "$ntptimer" -ge 600 ]; then
        /usr/bin/logger -st "ntpbootwatchdog" "NTP failed to sync after 10 minutes - please check immediately!"
        exit 1
    else
        /usr/bin/logger -st "ntpbootwatchdog" "NTP has synced!"
    fi
fi

Create or edit /jffs/scripts/init-start

#!/bin/sh
sh /jffs/scripts/ntpbootwatchdog.sh & #make sure NTP starts

Make sure both are executable

chmod +x /jffs/scripts/ntpbootwatchdog.sh
chmod +x /jffs/scripts/init-start

 

[Lord Lovaduck]

Hi Jack! Thanks for creating this! I may have this problem, in many cases addons won't start when my router gets powered off and on, either manually or worse (power cuts and brownouts are common here and my UPS is down, working on a building another).
I guess this script is installed when I choose "Enable NTP watchdog script" in SCMerlin webui? Correct?
Let's see how it goes now!

 

[SomeWhereOverTheRainBow]

Do you find that NTP will often taken longer than 5 minutes to sync, causing some addons to fail to start? If so, please read on for a workaround!

NTP "aggressive" syncing on boot while I thrash out a proper fix
Create /jffs/scripts/ntpbootwatchdog.sh

#!/bin/sh
if [ "$(nvram get ntp_ready)" -eq 1 ]; then
    /usr/bin/logger -st "ntpbootwatchdog" "NTP is synced, exiting"
else
    /usr/bin/logger -st "ntpbootwatchdog" "NTP boot watchdog started..."
    ntptimer=0
    while [ "$(nvram get ntp_ready)" -eq 0 ] && [ "$ntptimer" -lt 600 ]; do
        if [ "$ntptimer" -ne 0 ]; then
            /usr/bin/logger -st "ntpbootwatchdog" "Still waiting for NTP to sync..."
        fi
        killall ntp
        killall ntpd
        service restart_ntpd
        ntptimer=$((ntptimer+30))
        sleep 30
    done
    
    if [ "$ntptimer" -ge 600 ]; then
        /usr/bin/logger -st "ntpbootwatchdog" "NTP failed to sync after 10 minutes - please check immediately!"
        exit 1
    else
        /usr/bin/logger -st "ntpbootwatchdog" "NTP has synced!"
    fi
fi

Create or edit /jffs/scripts/init-start

#!/bin/sh
sh /jffs/scripts/ntpbootwatchdog.sh & #make sure NTP starts

Make sure both are executable

chmod +x /jffs/scripts/ntpbootwatchdog.sh
chmod +x /jffs/scripts/init-start

It happens almost instantaneously with this script.

 

[SomeWhereOverTheRainBow]

Hi Jack! Thanks for creating this! I may have this problem, in many cases addons won't start when my router gets powered off and on, either manually or worse (power cuts and brownouts are common here and my UPS is down, working on a building another).
I guess this script is installed when I choose "Enable NTP watchdog script" in SCMerlin webui? Correct?
Let's see how it goes now!

You have the correct procedures.

 

[GoNz0]

I had hoped this would sort my issue but...

ntpbootwatchdog: Still waiting for NTP to sync...

 

[alchemy]

I use the "Enable NTP boot watchdog script" option in scMerlin, never had any issues...

 

[johndoe85]

I use the "Enable NTP boot watchdog script" option in scMerlin, never had any issues...

Apr 17 17:11:33 ntpbootwatchdog: Still waiting for NTP to sync...
Apr 17 17:11:33 rc_service: service 23562:notify_rc restart_ntpd
Apr 17 17:11:33 custom_script: Running /jffs/scripts/service-event (args: restart ntpd)
Apr 17 17:11:33 ntpd: Started ntpd
Apr 17 17:11:33 custom_script: Running /jffs/scripts/service-event-end (args: restart ntpd)
Apr 17 17:11:34 timeserverd: Waiting for NTP to sync...

That did not solve this issue.

 

[SomeWhereOverTheRainBow]

Apr 17 17:11:33 ntpbootwatchdog: Still waiting for NTP to sync...
Apr 17 17:11:33 rc_service: service 23562:notify_rc restart_ntpd
Apr 17 17:11:33 custom_script: Running /jffs/scripts/service-event (args: restart ntpd)
Apr 17 17:11:33 ntpd: Started ntpd
Apr 17 17:11:33 custom_script: Running /jffs/scripts/service-event-end (args: restart ntpd)
Apr 17 17:11:34 timeserverd: Waiting for NTP to sync...

That did not solve this issue.

why don't you try switching to chronyd? i have heard alot of users having better results and accuracy with it.

 

[Yota]

Well done, it reduced my NTP sync time from 2 minutes after power up to 1 minute 20 seconds.

I've never understood why the NTP client in Asuswrt is so sluggish, even though I'm already using the IP address as the server to reduce the time taken by dns.

 

[Markfree]

Is this script intended only for NTPD?
Is there a parallel to Chrony or is it not struck by slow syncing?

 

[SomeWhereOverTheRainBow]

Is this script intended only for NTPD?
Is there a parallel to Chrony or is it not struck by slow syncing?

So the watch dog script runs in the background after init-start. it waits for ntp, if it waits too long, then it gives NTP daemon a swift kick start. It runs in the background so it shouldn't hinder any other processes.


@Jack Yaz Comment says it all

Do you find that NTP will often taken longer than 5 minutes to sync, causing some addons to fail to start? If so, please read on for a workaround!

NTP "aggressive" syncing on boot while I thrash out a proper fix
Create /jffs/scripts/ntpbootwatchdog.sh

 

[Maverickcdn]

Can add this to the bottom of the script to easily log how long NTP took to sync at boot

TZ="$(cat /etc/TZ)"
export TZ
ntp_set="$(grep "Initial clock set" /tmp/syslog.log 2>/dev/null | tail -n1 | cut -c -15)"   # find NTP sync time in log
[ -z "$ntp_set" ] && /usr/bin/logger -st "ntpbootwatchdog[$$]" "Script had errors, couldn't find NTP sync in logs" && exit 1   # if not found exit
found_epoch="$(/bin/date --date="$(/bin/date +'%Y') $ntp_set" -D '%Y %b %e %T' +'%s')"   # NTP sync time in epoch
epoch_diff="$((found_epoch - $(($(/bin/date +'%s') - $(awk '{print $1}' /proc/uptime | cut -d'.' -f1))) ))"   # secs between boot and NTP sync
if [ "$epoch_diff" -gt "$(awk '{print $1}' /proc/uptime | cut -d'.' -f1)" ] || [ "$epoch_diff" -lt 0 ] ; then   # validate
        /usr/bin/logger -st "ntpbootwatchdog[$$]" "Script had errors, epochdiff gt uptime or a negative value" && exit 1
fi
sync_diff="$(printf '%d min(s) %d sec(s)\n' $((epoch_diff%3600/60)) $((epoch_diff%60)))"
/usr/bin/logger -st "ntpbootwatchdog[$$]" "NTP took $sync_diff to sync after boot up"

 

[Markfree]

Can add this to the bottom of the script to easily log how long NTP took to sync at boot

TZ="$(cat /etc/TZ)"
export TZ
ntp_set="$(grep "Initial clock set" /tmp/syslog.log 2>/dev/null | tail -n1 | cut -c -15)"   # find NTP sync time in log
[ -z "$ntp_set" ] && /usr/bin/logger -st "ntpbootwatchdog[$$]" "Script had errors, couldn't find NTP sync in logs" && exit 1   # if not found exit
found_epoch="$(/bin/date --date="$(/bin/date +'%Y') $ntp_set" -D '%Y %b %e %T' +'%s')"   # NTP sync time in epoch
epoch_diff="$((found_epoch - $(($(/bin/date +'%s') - $(awk '{print $1}' /proc/uptime | cut -d'.' -f1))) ))"   # secs between boot and NTP sync
if [ "$epoch_diff" -gt "$(awk '{print $1}' /proc/uptime | cut -d'.' -f1)" ] || [ "$epoch_diff" -lt 0 ] ; then   # validate
        /usr/bin/logger -st "ntpbootwatchdog[$$]" "Script had errors, epochdiff gt uptime or a negative value" && exit 1
fi
sync_diff="$(printf '%d min(s) %d sec(s)\n' $((epoch_diff%3600/60)) $((epoch_diff%60)))"
/usr/bin/logger -st "ntpbootwatchdog[$$]" "NTP took $sync_diff to sync after boot up"

Great tip. Now I'll start monitoring that sync time.

 

[Jeffrey Young]

why don't you try switching to chronyd? i have heard alot of users having better results and accuracy with it.

Correct me if I am wrong, even Jack's NTPMerlin script waits for Asus's NTP be get synced first before attempting to start Chrony. Perhaps I am wrong about this, but that is how I read his script. I would have thought it would not have mattered if Asus NTP was synced or not when using chrony.

 

[SomeWhereOverTheRainBow]

Correct me if I am wrong, even Jack's NTPMerlin script waits for Asus's NTP be get synced first before attempting to start Chrony. Perhaps I am wrong about this, but that is how I read his script. I would have thought it would not have mattered if Asus NTP was synced or not when using chrony.

Ymmv you bring up a good point. Thanks for pointing it out.

 

[SomeWhereOverTheRainBow]

Correct me if I am wrong, even Jack's NTPMerlin script waits for Asus's NTP be get synced first before attempting to start Chrony. Perhaps I am wrong about this, but that is how I read his script. I would have thought it would not have mattered if Asus NTP was synced or not when using chrony.

NTP is highly subjective these days, you have a select few who ride with their wan dns blank, then you have those who have it set "properly" and yet dns still hangs or doesn't set properly. And you have developers that treat the clock as something that must be set before their script proceeds. Philosophically, who is correct on the matter? Or does it really matter? Idk. So it really is a Ymmv topic.

 

[Jeffrey Young]

I don't know what the reason is for waiting for Asus's NTP to sync before replacing it with another time server.

Unless Entware itself needs the clock set to start (perhaps the way Diversion tinkers with Entware), if someone is really having a dodge issue with the Asus NTP not starting, one could try to setup and start Chrony right from the post-mount script and bypass the Entware init.d startup script altogether. Chrony is, after all, just another Entware package. Jack's graphs and nifty webpage is nice, but one does not really need it.

You would likely have to manually add some firewall rules as well (force router as NTP Source, etc.)

 

[SomeWhereOverTheRainBow]

I don't know what the reason is for waiting for Asus's NTP to sync before replacing it with another time server.

Unless Entware itself needs the clock set to start (perhaps the way Diversion tinkers with Entware), if someone is really having a dodge issue with the Asus NTP not starting, one could try to setup and start Chrony right from the post-mount script and bypass the Entware init.d startup script altogether. Chrony is, after all, just another Entware package. Jack's graphs and nifty webpage is nice, but one does not really need it.

You would likely have to manually add some firewall rules as well (force router as NTP Source, etc.)

Even skynet waits for ntp.

 

[SomeWhereOverTheRainBow]

I don't know what the reason is for waiting for Asus's NTP to sync before replacing it with another time server.

Unless Entware itself needs the clock set to start (perhaps the way Diversion tinkers with Entware), if someone is really having a dodge issue with the Asus NTP not starting, one could try to setup and start Chrony right from the post-mount script and bypass the Entware init.d startup script altogether. Chrony is, after all, just another Entware package. Jack's graphs and nifty webpage is nice, but one does not really need it.

You would likely have to manually add some firewall rules as well (force router as NTP Source, etc.)

As for your question about waiting for the router to synced the time before starting an ntpdeamon from entware, I imagine the reason is because you don't want the routers ntp to somehow negate the time of the separate ntpdaemon. We have no real control over when that process will finish and the ntp sync variable is set dynamically once it does. So the whole arguement is that somehow if the routers built in ntp daemon continues the sync process somehow, then there may be a problem. But I am on the side of objective thinking. I would hope that the developer put this in place with the user in mind and not just because of a personal philosophy, but that is why this whole topic is so subjective.

 

[Jeffrey Young]

As for your question about waiting for the router to synced the time before starting an ntpdeamon from entware, I imagine the reason is because you don't want the routers ntp to somehow negate the time of the separate ntpdaemon. We have no real control over when that process will finish and the ntp sync variable is set dynamically once it does. So the whole arguement is that somehow if the routers built in ntp daemon continues the sync process somehow, then there may be a problem. But I am on the side of objective thinking. I would hope that the developer put this in place with the user in mind and not just because of a personal philosophy, but that is why this whole topic is so subjective.

I can get on board with that premise - and also agree with you. I was also thinking also that the Asus watchdog timer would likely interfere as well if the Asus NTP does not sync (keep trying to restart and muck up any alternative). I wonder what Asus's NTP does if you leave the server fields in the GUI blank.

I would play, but truth be told, I am working on replacing my AC86U (well, making it an AP) with a RasPi (Ubuntu) Router. Has been an interesting education getting everything to work and play nice (VLANs for Guest network, (DHCP, AdGuardHome, Chrony, my adaptation of SpdMerlin, SSL Certificate management, Reverse Proxy NGINX, Anti Virus, etc.). Currently working on getting domain rewrites for my AD to work properly in ADH). Chrony was probably the easiest component to set up. Merlin has been great, but it is kinda reaching the end of what I can do with it.

Great discussion.....