Mark Corbin

This issue occurred overnight last night on my RPI3 - strangely enough it was at 41 minutes past the hour as previously reported. Log file here --> [openvpn-unit-journal.txt](https://github.com/balena-os/meta-balena/files/4938444/openvpn-unit-journal.txt) Don't know...

The merge of #2014 will only fix this for instantaneous reboots where the outage time is

I'm going to close this issue based on the update to treat default servers as pools. This issue can always be re-opened if problems persist.

The clock synchronisation status as reported by `timedatectl` is determined by checking that the `maxerror` value in the kernel `timex` structure is less than 16000000 (16 seconds). If the value...

@alexgg It seems that `chrony waitsync` is only useful for detecting initial synchronisation. I haven't found any circumstances yet where it changes from `synchronised` back to `unsynchronised`. For example, I...

Looks like the latest release of `chrony` (4.0) may have some improvements in this area. From the `NEWS` file: ``` * Update clock synchronisation status and leap status more frequently...

@curcuz I've looked at the device from the support thread and can't see any reason why DBus/timedatectl should be reporting loss of sync. It looks `chrony` synchronised at boot (all...

I had a further look at the above support thread and found that `chrony` was reporting some strange values for `root dispersion` and `skew`: ``` Reference ID : ADF921CF (unifi.it-risch.de)...

@floion This isn't fixed yet. The kernel synchronisation status is independent of the `chrony` status and at the moment it's not entirely clear how to best relate one to the...

Upon review I don't think that it is necessary to include information regarding the incoming UDP ports for chrony as it seems that this is normally handled transparently by stateful...