User script for ntpd_synced

[dave14305]

I think it would be useful to have a user script that could run when ntpd_synced is run after a successful NTP sync. Today, scripts have to loop and wait for ntp_ready to be set to 1. Why not a triggered event when ntp is synced?

I'm specifically thinking about my use case where I would start Unbound without the DNSSEC validator module enabled, but once ntp is synced, I would rewrite the config to enable the validator module and reload Unbound, similar to how dnsmasq and stubby get restarted after time is synced.

It may not be as simple as adding a run_custom_script command near the end of ntpd_synced_main, but has this idea been considered and abandoned before? Any other use cases that would benefit from a triggered NTP sync notification?

 

[SomeWhereOverTheRainBow]

I think it would be useful to have a user script that could run when ntpd_synced is run after a successful NTP sync. Today, scripts have to loop and wait for ntp_ready to be set to 1. Why not a triggered event when ntp is synced?

I'm specifically thinking about my use case where I would start Unbound without the DNSSEC validator module enabled, but once ntp is synced, I would rewrite the config to enable the validator module and reload Unbound, similar to how dnsmasq and stubby get restarted after time is synced.

It may not be as simple as adding a run_custom_script command near the end of ntpd_synced_main, but has this idea been considered and abandoned before? Any other use cases that would benefit from a triggered NTP sync notification?

This is a great idea, but the main problem with the NTP is it revolves around being able to maintain some level of accuracy and there is no way to control when the time will actually sync could take 10 seconds or could take 30 seconds., I would skip the idea of starting unbound period, atleast until ntp is synced, let it default dnsmasq first (like it has always been the case).


The idea that you would like it to be an Event makes the most sense tho because this allows for it to occur once NTP syncs versus something that is actually "waiting".

 

[Dabombber]

You could just hook one of the existing scripts which are run at the end of ntpd_synced_main.

Spoiler: service-event/service-event-end

#!/bin/sh

if [ "$1_$2" = 'restart_diskmon' ] && [ ! -f /tmp/.ntpdsynced ] && [ "$(nvram get ntp_ready)" = '1' ]; then
    touch /tmp/.ntpdsynced
    # do stuff
fi

 

[dave14305]

You could just hook one of the existing scripts which are run at the end of ntpd_synced_main.

Spoiler: service-event/service-event-end

#!/bin/sh

if [ "$1_$2" = 'restart_diskmon' ] && [ ! -f /tmp/.ntpdsynced ] && [ "$(nvram get ntp_ready)" = '1' ]; then
    touch /tmp/.ntpdsynced
    # do stuff
fi

I though about this, but imagined it would be smoother with a dedicated user script. But this is a very good workaround!

 

[SomeWhereOverTheRainBow]

I though about this, but imagined it would be smoother with a dedicated user script. But this is a very good workaround!

My concern would be does it execute on every type of potential time sync or only for initial time sync?

 

[dave14305]

My concern would be does it execute on every type of potential time sync or only for initial time sync?

It would run if the nvram variable is not set and the NTP action is not "step". So I assume it's good.

Anyway, the intention of this thread is to propose the ntp synced event as a first-class citizen in the world of Merlin User Scripts.

 

[SomeWhereOverTheRainBow]

It would run if the nvram variable is not set and the NTP action is not "step". So I assume it's good.

Anyway, the intention of this thread is to propose the ntp synced event as a first-class citizen in the world of Merlin User Scripts.

yes my point to support your efforts as it seems it would be required for any ntp-plethora

 

[RMerlin]

It can be both a good and a bad idea, depending on how people use it.

If people decide to use that as a dumping ground to start all of their services, then they are simply trading a racing condition (starting before ntp is set) for another one (starting before a USB disk is mounted, for example).

The only good use I can think of for such an event script is to signal an already started event through kill -SIGXXX that time has just been set, and it can now adjust accordingly (reload its config, restart itself, etc...).

So right now, I'm worried about people misusing such a script. I'll have to think some more about it before taking a decision.

 

[Yota]

I would love to see some new features added to Merlin firmware.

I think it would also be a good idea to add the press wps button to run a custom script. I saw some wps features from the 3.0.0.3.108.4 firmware in the watchdog. but long ago it was disabled.
And, does anyone know how to implement a similar way using sh scripts without editing the whole firmware?

Thank you.

@Dabombber

 

[Martineau]

I would love to see some new features added to Merlin firmware.

I think it would also be a good idea to add the press wps button to run a custom script. I saw some wps features from the 3.0.0.3.108.4 firmware in the watchdog. but long ago it was disabled.
And, does anyone know how to implement a similar way using sh scripts without editing the whole firmware?

….asked many times and answered WPS Button change function ??

 

[Yota]

….asked many times and answered WPS Button change function ??

Yes, I've seen it, in fact I've seen almost every thread about WPS button functions. So I was looking at the source code, and found that Merlin used to implement a similar function.

 

[SomeWhereOverTheRainBow]

It can be both a good and a bad idea, depending on how people use it.

If people decide to use that as a dumping ground to start all of their services, then they are simply trading a racing condition (starting before ntp is set) for another one (starting before a USB disk is mounted, for example).

The only good use I can think of for such an event script is to signal an already started event through kill -SIGXXX that time has just been set, and it can now adjust accordingly (reload its config, restart itself, etc...).

So right now, I'm worried about people misusing such a script. I'll have to think some more about it before taking a decision.

Have you thought about this some more yet?

 

[RMerlin]

Have you thought about this some more yet?

No.

 

[SomeWhereOverTheRainBow]

No.

I agree with your original assessment on the matter. While "some" scripts may have a mission critical feature such as encryption, or dnssec, that requires an accurate type sync, there are too often those scripts that wait for ntp to sync for non-critical reasoning such as accurate log time stamps. In this regard, I feel it is more prudent to look for ways to eliminate hindrances to ntp sync, than to hold up too many processes waiting for the clock sync.