run ntpdate in reactivate

[geofft]

Apparently sometimes cluster machines get their clock skewed far enough away from the true time that you can't use Kerberos any more. We should run ntpdate -u time.mit.edu in reactivate (since at reactivation time, nothing should be caring about the clock being monotonic and continuous).

[andersk]

You’re not supposed to run ntpdate(8) while ntpd is running, and in fact this is not supposed to work at all.

ntpdate will decline to set the date if an NTP server daemon (e.g.,
ntpd) is running on the same host.

[jdreed]

We could run gettime(8) instead of ntpdate(8).

Alternatively, run a nightly cron job that shuts down NTP, runs ntpdate, then restarts NTP.

This assumes there isn't a "No, really" option for NTP that will force it to sync the time regardless of whether it thinks it's a good idea or not.

[andersk]

Replying to jdreed:

We could run gettime(8) instead of ntpdate(8).

The objection isn’t the exact command used to set the date; it’s that setting the date in any way while ntpd is running will confuse its statistics, which will probably make it even more inaccurate in the future.

Alternatively, run a nightly cron job that shuts down NTP, runs ntpdate, then restarts NTP.

That might work better.

[jdreed]

In fact, infinite-loop is now 14 seconds out of sync, yet ntpd seems fine with this. It is increasingly unclear to me that ntpd is actually able to keep clocks in sync.

[jdreed]

s/14/22/.

Why did we stop running gettime(8) at boot?

[jdreed]

r25626/reactivate 2.0.37

[jdreed]

I got bitten by rtkit-daemon again today, and the TTL has expired.
2.0.37->dev