To know that a disconnection from the server occurred
There's no "standing" connection to an NTP server, so no "disconnection" can really happen.
systemd-timesyncd does not give any warning that the server is unreachable.
Because that's not a problem! You don't need to be "connected" to a an NTP server for your time to be synchronized (as said, NTP is not a protocol that even knows the concept of a connection).
What you need to do is, at intervals, check the difference between your local clock and your reference clock. These intervals can typically be rather long. Clocks drift, but clock drifts are in the order of 100s of parts-per-million; so trying to check the difference between your clock and a reference clock every, say, 5000 s is more than enough to know whether you're synchronized. Often, tools like systemd-timesyncd poll more often, to have a way of having a faster feedback loop to steer your computer's clock speed in the right direction.
So, I think you have an inaccurate idea of how NTP-based clock synchronization works: it works by steering the speed of your computer's clock to catch up or fall back to the reference clock's time based on discrete-point time offset measurements. And due to the low error of clock frequencies to begin with, there's no benefit to having these measurements very often. On the contrary, you do them rarely, because otherwise the measurement noise (effectively: jitter) in NTP affects your local time.
Synchronization is not something that happens at a specific time, it's a state your system is in. If your local clock and the NTP-received time information differ (and they almost always do – no oscillators in this universe are exactly identical, and there's noise in the system), then timesyncd tells your kernel to adjust the clock speed such that your clock, based on its own history compared to NTP-supplied time information, becomes time-synchronous and runs at the same speed as the NTP-supplied reference. Because your clock drifts, and because there's uncertainty in all the observations involved, this is not a one-off process but an adjustment that happens over time.
Thus, the NTP server being unavailable is not a problem in itself – it just changes the priors about quality of NTP information, and thus increases the period at which NTP queries are sent.
it is not possible to see by timedatectl status that the systemd-timesyncd is not synchronized to the serve
Err,
System clock synchronized: yes
says that your synchronization is still in reliable range. So, yes, for systemd-timesyncd's definition of synchronization, you're still synchronized!
A computer's clock doesn't "suddenly" fall out of synchronization. It slowly drifts. Being a few minutes without internet connection isn't a problem!
I need to restart the systemd-timesyncd service.
See man systemd-timesyncd instead:
timedatectl(1)'s timesync-status or show-timesync command can be used to show the current status of this service.
So, no need to restart the service. (That's generally very much not what you want to do if you need long-term stable time synchronization, as it has side-effects and might forget state; see the noise discussion above. Keep the service running.)
timedatectl show-timesync
has all the information you need: The last NTP message (which contains the timestamp of said NTP message, i.e., when the last NTP request succeeded); the interval at which NTP is currently polled, and the maximum allowable interval for polling. Only if that maximum interval is has been exceeded since the last poll, you'd be in a situation where your computer can't really give you any sensible bounds on how far "off" NTP time you are. And that you'd also see very easily, by checking the NTPSynchronized= field in
timedatectl show
I'm not sure why you're actually trying to check NTP synchronization status regularly – that's actually timesyncd's job – but as a illustration for why you really should not restart timesyncd all the time: timedatectl timesync-status will tell you the current jitter estimate (it's an estimate of the jitter's standard deviation). The higher the jitter, the less precisely you know what time it is.
Try this:
- let your computer run for > 20 minutes, connected to the internet. Check the jitter.
- Disconnect from the internet. Wait 5 minutes, check jitter.
- wait (still offline) for an hour, and check the jitter.
- Then, connect to the internet, wait for 5 minutes, check jitter.
- let your computer run for an hour again, check jitter.
- Then restart timesyncd. Check jitter.
- wait 5 minutes. Check Jitter.
What's worse in terms of jitter estimate? losing internet connectivity for an hour, or restarting timesyncd?
