On Tue, 24 Jun 2014, Henrique de Moraes Holschuh wrote:
start ntpd with the '-g' option to fix that (add it to /etc/default/ntp).
That doesn't work, as this option was already in use.
We used to apply drift correction (stored in /etc/adjtime) when we still ran
hctosys / systohc during system boot/shutdown (refer to
/etc/init.d/hwclock*). I am unsure whether we still run that properly.
So, if you cannot live with the "ntpd -g" skip on boot/resume, you'll likely
have to set up the adjtimex package manually, and configure the hwclock
package (also manually).
I found the following recommendation in the adjtimex man. I'll try it
hwclock can be used to approximately correct for a constant drift in the
hardware clock.
In this case, "hwclock --adjust" is run occasionally.
The user needs to set the time with "hwclock --set" several times
over the course of a few days so hwclock can estimate the drift rate.
during that time, ntpd should not be running After you have run
"hwclock --set" for the last time, it's okay to start ntpd.
Anyway, the fact that this problem appeared just a few days ago on a machine
running since about 5 years seems indicate a hardware problem (battery?)
best regards,
--
Pierre Frenkiel
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/alpine.deb.2.10.1406250902340.2...@pfr2.frenkiel-hure.net
