It’s not that it’s not running, it’s that ntpd in startup phases can have big steps in some configs. Also alert on large clock drift. If you run cassandra, you need alerts on ntpd
> On Jul 15, 2026, at 8:13 AM, Yakir Gibraltar <[email protected]> wrote: > > Configure Cassandra to start after ntpd service , easy on systemd. > > Thank you, Yakir Gibraltar > > On Wed, Jul 15, 2026, 10:47 Panagiotis Melidis via user > <[email protected] <mailto:[email protected]>> wrote: >> Hi all, >> >> >> >> I'm looking for guidance on a scenario involving NTP clock skew and its >> impact on Cassandra data. >> >> >> >> If an NTP malfunction causes the system clock on multiple Cassandra nodes to >> jump far into the future (e.g., 100 years), any writes processed during that >> window will carry far-future timestamps. Once the clock is corrected, these >> entries effectively become permanent and shadow any new write/delete in the >> affected partition keys. >> >> >> >> The only viable recovery approach at scale I've been able to identify is >> truncating the affected tables. >> >> Are there any other known viable recovery procedures that don't require a >> full truncate? >> Are there any known existing or planned preventive measures in Cassandra to >> guard against such scenarios? >> >> >> Any pointers to prior discussions, tooling, or patches would be greatly >> appreciated. >> >> >> >> Thanks. >>
