I haven't personally seen anything about this across my fleet; anyone here
seeing tracks from it?
Cheers,
-- jra
Reddit has a big post on it.
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
I haven't personally seen anything about this across my fleet; anyone here
seeing tracks from it?
-snip-
-snip-
"One explanation that has gained traction online as users scramble for
answers is the suggestion that a cluster of time servers may have lost
connection with an external source that syncs the time and date."
Haven't seen it, but if people are reporting sudden hour
offsets, on the first Monday in April, I'd bet on a DST implementation
bug that hijacked the system clock on their servers.
This doesn't look like the sort of error you'd get with a free
running clock.
--msa
Majdi S. Abbas <msa@latt.net>:
Haven't seen it, but if people are reporting sudden hour
offsets, on the first Monday in April, I'd bet on a DST implementation
bug that hijacked the system clock on their servers.This doesn't look like the sort of error you'd get with a free
running clock.
I concur, about the one-hour shift anyway. The random garbage times
aren't really likely either - jumps that large would tend to get the
source rejected as a falseticker.
It's a weird set of symptoms that rather looks as if they hit two different
failure modes at once. Dunno.
One of our NTPsec devs posted the link on one of our project channels and
suggested maybe we ought to call M$ with an offer of help...
It's not entirely clear whether it's *entirely* MSWin clients; I can't
imagine anything being pointed at those servers that wasn't, though, cause
who the hell would?
Anyone smart enough to manually select NTP upstreams isn't going *there*...
Cheers,
-- jra