[Pkg-sysvinit-devel] NTP bites dovecot

Henrique de Moraes Holschuh hmh at debian.org
Thu Jun 18 03:28:04 UTC 2009

On Tue, 16 Jun 2009, martin f krafft wrote:
> also sprach Henrique de Moraes Holschuh <hmh at debian.org> [2009.06.16.0430 +0200]:
> > > 1. laptops that suspend/resume
> > 
> > What kind of junk moves time backwards on suspend/resume?
> An inaccurate hardware clock.

Ehh, if the kernel is letting a RTC move time *backwards* on a kernel
resume handler, it is a big bad bug and needs fixing and a backport to

If it is userspace that is doing it, it can be fixed by applying the
proper adjustment to the RTC, hwclock can do it through /etc/adjtime.

See also package adjtimex.

> > > 2. machines that are not always online but run something like
> > > ntpdate or chrony or similar in the if-up hook.
> > 
> > That's broken beyond belief if it steps the clock backwards.
> Not if your hardware can't keep up.

I don't follow... if your RTC is too fast, adjtimex lets you compensate
for it.  If the kernel ignores that when restoring the system time after
a suspend cycle from the RTC, it is a bug and needs fixing.

As for running ntpdate/ntp -g (and whatever makes chrony step the clock
backwads) outside of early boot is well into Don't Do That territory...

> And yes, it sucks to be stuck with sub-par hardware.

I can imagine.  But this really _is_ something we should be able to work
around properly without moving system time backwards after early
userspace.  That's why ntp has that driftfile thing, and why hwclock has
/etc/adjtime, and why adjtimex exists.

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

More information about the Pkg-sysvinit-devel mailing list