On Tue, 16 Jun 2009, martin f krafft wrote: > also sprach Henrique de Moraes Holschuh <h...@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 -stable. 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 _______________________________________________ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel