A bug in gpsd upon which some NTP servers rely, has been known for a couple of months, but it hasn't really become general knowledge until recently, just before the October 24, 2021 rollover that may set some NTP servers' clocks back to 2002. A patch for GPSD fixes the bug.
Since my company doesn't have high time synchronization needs with the outside world, we use the NTP pool servers as our ultimate source of accurate time. (Everything in the network synchronizes with a single device in the network, which synchronizes with the pool servers.)
The NTP pool website doesn't have any news after 2019, but interestingly, one of those items is about another GPSD week rollover that happened in 2019.
Various institutions belong to the NTP server pool on a voluntary basis, and so they're each going to have their own means of getting accurate time.
Is it known whether any of these servers use gpsd?
This other Server Fault question doesn't address the issue, but it does give an example of why the problem might be so complicated.
You could probably work out which of your current upstreams use
gpsd
by checking their reference id. I don't rungpsd
, but some quick web searches suggest that it will probably show up asPPS
orGPS
. Then you could manually replace them before the known GPS week rollover date.However, as long as you have sufficiently diverse upstreams and are using the pool with the
pool
directive in your configuration, you can probably do nothing and be fine. The reason for this is twofold:It's probably fine just to check it before the rollover and check it again afterwards.