Ticket #749 (closed defect: fixed)

Opened 10 years ago

Last modified 9 years ago

run ntpdate in reactivate

Reported by: geofft Owned by:
Priority: normal Milestone: Precise Release
Component: -- Keywords:
Cc: Fixed in version: debathena-reactivate 2.0.38
Upstream bug:

Description

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).

Change History

comment:1 Changed 10 years ago by 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.

comment:2 follow-up: ↓ 3 Changed 10 years ago by 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.

comment:3 in reply to: ↑ 2 Changed 10 years ago by 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.

comment:4 Changed 10 years ago by 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.

comment:5 Changed 10 years ago by jdreed

s/14/22/.

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

comment:6 Changed 9 years ago by jdreed

  • Status changed from new to committed
  • Milestone changed from The Distant Future to Precise Beta

comment:7 Changed 9 years ago by jdreed

  • Status changed from committed to development

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

comment:8 Changed 9 years ago by jdreed

  • Fixed in version set to debathena-reactivate 2.0.38

comment:9 Changed 9 years ago by jdreed

  • Status changed from development to proposed

comment:10 Changed 9 years ago by jdreed

  • Status changed from proposed to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.