What does /sbin/ntpd_synced do?

[cmkelley]

I presume it does something more than set the nvram ntp_ready to 1? I noticed the firmware calls it when it launches ntpd (and apparently every 11 minutes as well, according the busybox usage for ntpd), although the entware installation of ntpd doesn't. /sbin/ntpd_synced is symlinked to /sbin/rc, as are quite a few other files in that directory.

I have a script that fetches time from my timeserver on my network as early as possible (it fetches by IP, so DNS doesn't even have to be up). I've just been using

nvram set ntp_ready=1
nvram commit

Should I be calling ntpd_synced as well? And if I using Entware's ntpd should I set up a cron job for it?

 

[RMerlin]

Calls ntpd_synced_main() in rc, with the event type as argument.

https://github.com/RMerl/asuswrt-merlin.ng/blob/mainline/release/src/router/rc/ntpd.c#L82

 

[cmkelley]

Calls ntpd_synced_main() in rc, with the event type as argument.

https://github.com/RMerl/asuswrt-merlin.ng/blob/mainline/release/src/router/rc/ntpd.c#L82

I actually don't know C at all, so I'm not really sure I follow it, but I don't see the point of calling it every 11 minutes (per the usage for the -S option).

 

[RMerlin]

ntpd calls it on every event, providing the event type as parameter. This is simply how ntpd works. It supports one event handler, and it's the job of that event handler to examine the type of event received, and act accordingly. Here, rc then does what it needs to do based on the event triggering it. For example, on a first sync it will set various appropriate nvram settings, restart time-sensitive services, instruct dnsmasq to start processing DNSSEC, etc...

In short, it's an ntpd event handler, and it reacts to the event as needed, and it does much more than just set an ntp_ready flag. If you override the router's own ntpd, then it becomes your responsibility to also properly inform the router of such events.

 

[cmkelley]

ntpd calls it on every event, providing the event type as parameter. This is simply how ntpd works. It supports one event handler, and it's the job of that event handler to examine the type of event received, and act accordingly. Here, rc then does what it needs to do based on the event triggering it. For example, on a first sync it will set various appropriate nvram settings, restart time-sensitive services, instruct dnsmasq to start processing DNSSEC, etc...

In short, it's an ntpd event handler, and it reacts to the event as needed, and it does much more than just set an ntp_ready flag. If you override the router's own ntpd, then it becomes your responsibility to also properly inform the router of such events.

Heh, the dangers of messing with stuff you don't understand. This is more for documentation in case someone else stumbles upon this thread.

Calling ntpd_sync from my script instead of just setting ntp_ready caused weird behaviour ... it seems like the router thought ntp never synced. Same thing if I didn't call ntpd_sync and also didn't set ntp_ready. I seem to have accidentally stumbled on the least-wrong method of setting the time early by calling my local ntp server, acknowledging that the correct method is to let the router set the time itself instead of me trying to set it as early as possible.

The first (calling ntpd_sync) causing problems doesn't really surprise me, but the second (not setting ntp_ready) does ... obviously I'm missing something, I would have thought that it would have continued as if I hadn't set the time, then eventually called its own routines to set the clock and proceeded normally. The law of unintended consequences I guess.

 

[RMerlin]

When calling ntpd_sync you need to also pass it the event type as parameter. On the initial clock sync for instance this event must be "step". Calling ntpd_sync without parameter won't do anything, and other parameters might have different results (right now I only monitor for "step" events, but other events might eventually be monitored in the future).

To know more about the various event types you would have to study the Busybox ntpd applet code.

 

[cmkelley]

When calling ntpd_sync you need to also pass it the event type as parameter. On the initial clock sync for instance this event must be "step". Calling ntpd_sync without parameter won't do anything, and other parameters might have different results (right now I only monitor for "step" events, but other events might eventually be monitored in the future).

To know more about the various event types you would have to study the Busybox ntpd applet code.

Ahhh, the light gets a little brighter. I was confused, because it appears at first blush that the firmware ntpd calls ntpd_sync without any parameters:

  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1141     1 AC3200   S     1432  0.5   0  0.0 /usr/sbin/ntp -t -S /sbin/ntpd_synced -p 192.168.x.y -p 192.168.x.z -l -I br0

But it appears from the busybox ntpd code that the argument for -S parameter is only the name of the program that is called; busybox ntpd adds the "step", "stratum", "periodic", or "unsync" parameter when calling the program.

Near as I can tell "step" is when there is a large step in the time (e.g. at bootup), "stratum" I think is if the stratum of the router were to change (such as changing from syncing to a stratum 1 source to a stratum 2 source; the router stratum would change from 2 to 3), "periodic" is every 11 minutes (no explanation for that readily apparent in the code), and "unsync" is if it is no longer able to sync to an NTP server.

So, if I set the time without calling "ntpd_synced step" then the system ntpd doesn't detect the large step and so never calls "ntpd_synced step". There must be some other mechanism though to call ntpd_synced if I set ntp_ready to 1, since I don't have issues if I do that.

I'm way too fascinated by time. I wish I had the bandwidth to figure out how to create something that made the cool graphs that @Jack Yaz's ntpmerlin makes, only accessed via a web page served by my Rasperry Pi time servers (yes, servers, I'm running 2, I generally get < 1msec accuracy according to the ntpmerlin).