amtm disk-check script and ntp

[bengalih]

So I was able to cut 100 seconds off my boot time by fixing up some things with my configuration.
The delay was coming from the disk-check script that is executed in pre-mount:

pre-mount

#!/bin/sh
. /jffs/addons/amtm/disk-check # Added by amtm

disk-check

while [ "$(nvram get ntp_ready)" = "0" ] && [ "$ntptimer" -lt "$ntptimeout" ]; do
    ntptimer=$((ntptimer+1))
    sleep 1
done

My problem was that my WAN connection doesn't get enabled until *after* disk mount because I use wpa_supplicant stored on the drive to do authentication.
Initially I had just removed the timer, but then I found a cleaner way to sync to a local time server and set ntp_ready to 1 fore the disk-check regardless (then put it back to 0 afterwards in a post-mount to allow the system to continue as normal).

Anyway - I was curious why the ntp sync is so important here to block for almost 2 minutes? Had I no local timesync server (and even now, it is possible that the sync will fail for any number of reasons), the process would still continue after 100 seconds regardless if time was synced or not. So, clearly it isn't an imperative, but I'd like to know why is is so important here?

thanks.

 

[ColinTaylor]

Anyway - I was curious why the ntp sync is so important here to block for almost 2 minutes?

Any addons that use encryption (e.g. VPN, DoH, etc.) need the router's time to be set correctly otherwise they won't work. So probably that and the general desire to have the correct time available to addon scripts should they need it.

 

[bengalih]

This is specifically in the "disk-check" script though, it puts a 100 second block before it will even proceed with the check.
It is possible he put it here because it goes from check > mount > then all services will start, so maybe he just thought it convenient to put there.
I would have thought it smarter to put in a post-mount script if it didn't have any direct bearing on checking the disk itself.

I was just curious if the actual fsck checks and equivalent he runs are somehow dependent (or safer) with a synced time.

I understand the importance of correct time for many things...just thought this was a strange place to put it since it blocks for 100 seconds before the disk mount.

 

[ColinTaylor]

Sorry, I thought that code was in the pre-mount script after the disk check. That's what it looked like in your post.

Now it makes more sense because otherwise the disk check log would always show the default date and time. I had to add similar code to my own bespoke pre-mount script for that reason.

 

[SomeWhereOverTheRainBow]

This is specifically in the "disk-check" script though, it puts a 100 second block before it will even proceed with the check.
It is possible he put it here because it goes from check > mount > then all services will start, so maybe he just thought it convenient to put there.
I would have thought it smarter to put in a post-mount script if it didn't have any direct bearing on checking the disk itself.

I was just curious if the actual fsck checks and equivalent he runs are somehow dependent (or safer) with a synced time.

I understand the importance of correct time for many things...just thought this was a strange place to put it since it blocks for 100 seconds before the disk mount.

He didn't put it in the post-mount itself because everytime post-mount would run you would have a 100 second delay when he is only interested in having 1 delay, which is the one for the specific disk check run. The goal isn't to cripple the post-mount script in its entirety, just the lesser script run of the disk check itself. The ultimate goal of the 100 second delay was so you didn't have multiple mounts competing for the disk check slot at the exact same time. @thelonelycoder thought very critically of the timings he put in place as to not create a race condition at boot.

 

[bengalih]

Sorry, I thought that code was in the pre-mount script after the disk check. That's what it looked like in your post.

Now it makes more sense because otherwise the disk check log would always show the default date and time. I had to add similar code to my own bespoke pre-mount script for that reason.

OK - so you are saying it is there just to have valid time in the log file, which is no different than wanting to have valid time in your syslog, or any other log to make it more accurate if you need to refer.

Personally, I still think blocking for 100 seconds for this was not a great call and could have been moved after the disk was mounted. Unlikely that anyone would need to refer to the disk log very frequently.

In any event, I just wanted to be sure I wasn't missing something that might have been more nefarious had the time not been set correctly.

In my case, if the date is off too far my wpa_supplicant won't authenticate to the internet and that is signal enough for me that something is wrong!

 

[SomeWhereOverTheRainBow]

And IIRC @ColinTaylor provided very critical support on this script as well.

 

[SomeWhereOverTheRainBow]

OK - so you are saying it is there just to have valid time in the log file, which is no different than wanting to have valid time in your syslog, or any other log to make it more accurate if you need to refer.

Personally, I still think blocking for 100 seconds for this was not a great call and could have been moved after the disk was mounted. Unlikely that anyone would need to refer to the disk log very frequently.

In any event, I just wanted to be sure I wasn't missing something that might have been more nefarious had the time not been set correctly.

In my case, if the date is off too far my wpa_supplicant won't authenticate to the internet and that is signal enough for me that something is wrong!

I think the timing was critical, think of mounting multiple drives or partitions. if you ran all disk checks at the exact same time. what is likely to happen?

 

[bengalih]

He didn't put it in the post-mount itself because everytime post-mount would run you would have a 100 second delay when he is only interested in having 1 delay, which is the one for the specific disk check run. The goal isn't to cripple the post-mount script in its entirety, just the lesser script run of the disk check itself.

Don't pre-mount and post-mount go hand in hand? Anytime that post-mount is called, pre-mount would have been called prior, no?
Also you would never have a delay as long as ntp was in sync.
While I think amtm is great, this isn't the first time I have noticed it being too aggressive at poking into other things. If something specific to amtm requires time-sync, then the check should happen prior to that specific thing, not create a ~2 minute block.
Don't really want to debate it - once I tracked down where the delay was coming from I was able to mitigate it better, but it wasn't apparent.
My main concern was making sure on the case that my time sync may fail I would understand the repercussions in relation to the disk-check.

 

[bengalih]

I think the timing was critical, think of mounting multiple drives or partitions. if you ran all disk checks at the exact same time. what is likely to happen?

nothing in the current script can prevent that, there isn't a staggered delay. It is a 100 second timer that will stop as soon as ntp is detected as ready. I don't know how the underlying process deals with multiple disk mounts (whether or not pre/post mounts run synchronously or not), but this script doesn't do anything to mitigate timing in that regard.

 

[SomeWhereOverTheRainBow]

nothing in the current script can prevent that, there isn't a staggered delay. It is a 100 second timer that will stop as soon as ntp is detected as ready. I don't know how the underlying process deals with multiple disk mounts (whether or not pre/post mounts run synchronously or not), but this script doesn't do anything to mitigate timing in that regard.

The best way to make sure the router time is set properly is to make sure a real world DNS address resides in the WAN DNS1 and WAN DNS2 Slots. Unfortunately, alot of users decide it to be rational to have these fields blank without considering the ramifications ( alternatively, they may have inadvertently put a DNS that isn't available before the clock syncs). I would recommend fixing any WAN DNS breaks if they exist instead of mitigating the undesired script behaviors. But I see in your Original post that yours is caused by a different mechanism (WPA supplicant).

 

[bengalih]

The best way to make sure the router time is set properly is to make sure a real world DNS address resides in the WAN DNS1 and WAN DNS2 Slots. Unfortunately, alot of users decide it to be rational to have these fields blank without considering the ramifications ( alternatively, they may have inadvertently put a DNS that isn't available before the clock syncs). I would recommend fixing any WAN DNS breaks if they exist instead of mitigating the undesired script behaviors.

As I mention in my OP, my WAN is not available until after my disk mounts. This is because I require a compiled wpa_supplicant package and supported libraries to support 802.11x authentication with AT&T's fiber network. So, in my case I will *never* be synced to a WAN source prior to my disk mount.
Luckily, I have internal NTP sources (domain controllers) that I call manually in pre-mount prior to this check. More likely than not they will be online and everything will proceed ok. If not, I force 'ntp_ready=1' so the disk-check doesn't get hung and then I turn it back to 0 after the mount to allow the native process to sync once it realizes I'm connected to the WAN.
I realize most people don't have the issue of having to have their disk mounted prior to WAN connect, but I have been wondering for months now why my reboot process was taking so long until I decided to sit down and actually audit the entire syslog at boot.

 

[SomeWhereOverTheRainBow]

As I mention in my OP, my WAN is not available until after my disk mounts. This is because I require a compiled wpa_supplicant package and supported libraries to support 802.11x authentication with AT&T's fiber network. So, in my case I will *never* be synced to a WAN source prior to my disk mount.
Luckily, I have internal NTP sources (domain controllers) that I call manually in pre-mount prior to this check. More likely than not they will be online and everything will proceed ok. If not, I force 'ntp_ready=1' so the disk-check doesn't get hung and then I turn it back to 0 after the mount to allow the native process to sync once it realizes I'm connected to the WAN.
I realize most people don't have the issue of having to have their disk mounted prior to WAN connect, but I have been wondering for months now why my reboot process was taking so long until I decided to sit down and actually audit the entire syslog at boot.

Yea, I can tell it sounds like most of the mishaps occurring in your router environment were unfortunate results of the environment conditions they were ran under. Not that there is anything "wrong" per say with your setup, but most users are not in these scenarios, so when script writers come up with the script, it hasn't been made a factor to consider. Typically the goal in mind is to make something that runs for the average router condition, but as you place more and more factors into the equation things become less and less "average". I am glad you managed to find something that works. Keep sharing things because your post may actually help someone else who is presented with the same conditions.

 

[SomeWhereOverTheRainBow]

OK - so you are saying it is there just to have valid time in the log file, which is no different than wanting to have valid time in your syslog, or any other log to make it more accurate if you need to refer.

Personally, I still think blocking for 100 seconds for this was not a great call and could have been moved after the disk was mounted. Unlikely that anyone would need to refer to the disk log very frequently.

In any event, I just wanted to be sure I wasn't missing something that might have been more nefarious had the time not been set correctly.

In my case, if the date is off too far my wpa_supplicant won't authenticate to the internet and that is signal enough for me that something is wrong!

Yea I would have assumed more nefarious motives as well, than just keeping an accurate log at boot time.