I was curious why device time was set so late in the boot process. Any process (ex: S50syslog-ng) that starts up before ntpd will potentially have the wrong time that can only be fixed after a resource of the service in question (ex: syslog-ng)
If a device does not have an internal clock, shouldn't ntpd/ntpclient be started immediately after the WAN interface is online?
The system clock is set early in the boot process to the latest timestamp in /etc/ (as I recall). For many things, this is "good enough" for many needs -- sort of a poor-man's battery-backed RTC.
As you note, some interface needs to be up, though not necessarily the WAN (for example, a local NTP server on the LAN). Also, you need DNS services to resolve the host names (especially if using pool servers). In some cases, you need a VPN established as well.
Yes, it could be moved "up" in the boot sequence, if you know what your situation is.
boot-time... network-time assignment is a "like to have" but we want to be operational first and foremost...
service time issues are service time issues
the issue is not so much when it's started... but
upstream / server issues are adapted for at a local level ( yes... you can add a delay of 300 seconds before sarting services or an ntp hotplug trigger.... but do you really want to? much easier to setup an ntp server on the lan )
whether or not a service is capable of waiting / watching / adapting to runtime updates...
Sorry, I do not really understand, what you mean.
Having complaint about the actual "good enough" solution myself already some time ago, regarding setting the time,I have to add my 2 cts, that such a policy does not result in best software quality possible. A "as good as possible" is more appropiate.
In detail, I had issues using early wireguard, because it also depended upon time stamps during connection establishment. Wireguard was started before correct time, but did not complete connection establishment, i.e. after sysupgrade, which led to initial time "in the past". It is not the correct approach to assume, that using one certain module you might need to know the internals of other ones, which might interfere.
Anyway, without RTC it should be best, to try as hard as possible to set time ASAP. Which means, to move the time setting to the begin of start-up chain. And not to the end.
It will adjust time to last time stamp earlier in the startup process.
ntpd as a daemon should continously try to get network time. So, as soon as network is up and a configured time server is reachable, time is adjusted.
Applying both, will come as close as possible to achievable optimum.
The "good enough" policy is making assumptions about other packages (modules) behaviour. Which is against very old, (may be forgotten ?) good software design philosophy.
In my tests on x86 the services got started within a few ms anyway and starting ntp early didn’t make noticeable difference.
I remember that because I had to patch busybox ntpd to keep resolving its peers in the first place, instead of failing right away.
If wireguard or its protocol handler implementation are not implemented with resolve/connect retries in mind, they will keep failing, regardless of where you move the ntpd init.
The services are launched in parallel, so the order of init scripts does not provide any ordering or depency guarantees.
Sure, starting ntpd a few ms earlier might be slight improvement but it will not solve this particular class of problems.
wireguard had replay protection, also based on timestamps. Packets from the past, from openwrt, were ignored on peer. Especially harmful after sysupgrade, as then time was set back into long ago, may be. And graceful time adjustment then took a while.
Anyway, I am wondering, how a "good enough solution" can be defended, when a best solution possible. Such "good enough solution" policies applied in various places are the reason for "non-deterministic" software, politely expressed.
I am not defending the "good enough solution", I want to point out that moving sysntpd early is not the optimal solution or even any solution to begin with. In my tests it didn't make a difference in behaviour at all.
The present start-up sequencing, coupled with a well-behaving network-time daemon, generally ensures that the time on the device is monotonically increasing after boot (there could be some degenerate cases around improper build time for a firmware image, or the like).
For most applications, this is sufficient.
I also acknowledge that WireGuard requires that time for a given peer be monotonically increasing over the duration of the session.
Putting aside the seemingly intractable problem of a device without a battery-backed RTC (which is not a complete solution, as the RTC may have forward drift) and requiring an active WireGuard connection to obtain time sync, one can argue that WireGuard should not be started until after time sync is obtained.
It has the side effect of RRD spamming the log with errors about the database being in the future.
That forces you to install ntpclient. It's a know issue but nobody seems interested in fixing it.